
PREFACE 


This manual is designed to familiarize Air Force personnel with the 
unique mission of 26 NORAD Region's SAGE Programming Agency. Non- 
technical language will be used so that both programmers and opera- 
tions, command and staff personnel will have a common reference con- 
cerning the scope of computer program design, documentation, mainte- 
nance, and testing responsibilities. Lack of clear communications 
between operations personnel (the users) and computer technicians has 
probably been the single greatest impediment to effective use of any 
computer system. This is an effort to minimize this difficulty. 
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MISSION OF SAGE PROGRAMMING AGENCY 


Provide technical programming support of SAGE computer programs to 
insure that, at all echelons of command within Aerospace Defense Com- 
mand, Commanders can: 

1. Exercise timely command and control over weapons and weapons 
support systems. 

2. Conduct the air battle on a real-time basis. 

3. Coordinate operational actions with and give support to oper- 
ational echelons above, below, and adjacent to them. 

4* Facilitate implementation of orders and instructions from 
NORAD to NORAD Region Combat Centers. 

5. Provide timely air battle information to the NORAD Combat Oper 
ations Cent'er. 

6. Maintain a high level of combat readiness through the use of 
simulation, evaluation, and recording functions of the SAGE program 
system. 
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THE COMPUTER PROGRAM 


The computer cannot accomplish its functions unless responding to a 
set of instructions. These instructions are known collectively as a com- 
puter program. Discrete areas within this set of instructions are called 
subprograms . 

Each operation carried on within a Direction Center during the proc- 
essing of an air defense problem is controlled by a separate subprogram. 
All subprograms together constitute the SAGE program system called the 
SAGE Operational Program. 

The air defense program may be divided up into major functional 
blocks such as the air surveillance or weapons direction area. The air 
surveillance area consists of a group of subprograms which compile and 
process information on air movements while the weapons direction portion 
uses surveillance data to direct the defense of a given area with mis- 
siles or manned aircraft. Some other major functional areas are displays, 
simulation, data reduction, and recording. In each area, subprograms 
perform a complex function automatically or semi-automatically as deter- 
mined by operations personnel through a system of switch actions capable 
of modifying the automatic features of the program system. 

The SAGE Operational Program together with the facility and utility 
program systems which support it is still the most complex computer pro- 
gram system in operation today. 
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HISTORY OF THE SAGE PROGRAMMING AGENCY 


Since 1965, Air Force personnel at Luke AFB have been developing 
the capability to accomplish computer programming tasks required to 
support the Aerospace Defense Mission. 

In 1966, the SAGE programming contractor, System Development Cor- 
poration, was tasked to train Air Force officers and NCO's to handle 
program maintenance functions. The results of this initial effort 
were highly successful. Air Force personnel rapidly acquired the tech- 
nical knowledge necessary to handle routine site maintenance tasks. 

Following this initial "Blue Suit" transition at all SAGE Direction 
Centers and Combat Centers, 26 Air Division (then 27 Air Div) continued 
training to handle test and acceptance as well as SAGE system maintenance 
functions. 

On 3 June 1968, 27 Test and Acceptance Agency was officially assigned 
the responsibility for verification of contractor-designed computer pro- 
grams and for system maintenance of these programs. By June 1969, the 
success of Air Force personnel in handling their technical responsibilities 
indicated that "Blue Suit" training should be further expanded to include 
the more sophisticated programming functions of design and version pro- 
duction. 

In November 1969, Commander, ADC, ordered that plans be drawn up and 
implemented to increase the capability of 26 Test and Acceptance Agency 
to handle all SAGE computer programming functions performed by contractor 
personnel. As a result, field site manning was reduced from nine to five 
programmers and 26 Test and Acceptance Agency manning was increased by 
twenty- one systems analysts and computer programmers. System Development 
Corporation was contracted to provide training in those areas which Air 
Force personnel required upgrading. 

On 1 July 1970, 26 Test and Acceptance Agency was redesignated 26 
SAGE Programming Agency (26DOSP) to more accurately identify the increased 
scope of technical responsibilities. 

Upon completing formal training (15 July 1970) Air Force systems 
analysts and computer programmers began on-the-job training to develop and 
refine procedures to design changes to the SAGE program system. 

On 30 June 1971, 26 NORAD Region will accept full responsibility for 
total technical support of the SAGE computer program system, thereby saving 
ADC more than $3.5 million per year without reducing Air Defense capability. 
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THE NATURE OF THE JOB AND THE PEOPLE 


The most common question asked of systems analyst/computer programmer 
personnel is--what do you do and why is it necessary? Too often the 
answer given is loaded with technical terms and abbreviations which con- 
fuse the asker, establish a communications block, and ultimately result 
in minimizing the effectiveness of programming support. 

Changes to SAGE computer programs are a continuing requirement. Most 
operational decisions affecting air defense strategy, tactics, weapons 
design, weapons capabilities, and organizational configurations have a 
major impact upon computer programs used within the system. In many 
cases, these decisions can be implemented rapidly in current programs. 

This responsiveness is directly related to the well documented SAGE pro- 
gram system in existence. However, some operational changes may require 
major changes within the program system. The impact of these major changes 
may act as restraints to implementing changes or result in technical analy- 
sis to find alternate or interim measures of satisfying operational require- 
ments . 

THE MAJOR TASK. OF 26 SAGE PROGRAMMING AGENCY IS TO CONVERT OPERATIONAL 
REQUIREMENTS INTO CHANGES TO COMPUTER PROGRAMS . The translation of require- 
ments from prose to computer language is a technical task which requires 
the use of , many skills. Within 26 SAGE Programming Agency, analysts and 
programmers have many different educational backgrounds which are needed 
to handle technical tasks: Mathematics, engineering, and computer science 
degrees are balanced by English, history, and general science education, 
all of which provide a necessary supplement to Air Force training in com- 
puter programming. In addition, the requirement for operational knowledge 
of air defense functions is met by officers and NCO‘s who have been assigned 
to SAGE Direction Centers as weapons controllers and aircraft control and 
warning technicians for several years prior to training as computer pro- 
grammers. This mix of technical and operational skills insures that realis- 
tic responsiveness to operational requirements is obtained. 
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SAGE PROGRAMMING AGENCY WORK FUNCTIONS 


Operational Design - Consists of designing and documenting changes to 
the SAGE system as directed by ADC. Design Change Suggestions are 
analyzed to determine feasibility, validity, and operational impact; a 
document is produced which states how the Design Change will be accom- 
plished. 

Design Implementation - Consists of flow charting and otherwise document- 
ing the program code required to implement the modifications specified 
by operational design changes. The implementation process includes cod- 
ing, testing, and submitting necessary changes to all technical documents 
for publication. 

Version Assembly - Consists of those technical tasks required to incorpo- 
rate all approved changes onto a new SAGE Master Tape. 

Version Testing - A series of realistic simulated environment tests and 
live environment tests used to verify that the SAGE computer program 
system operates according to system specifications. 

Program Maintenance - Analysis and response to suspected computer program 
problems reported by users and test personnel. The result of maintenance 
tasks will' be timely repair of verified problems or clarification of 
technical and operational documents which were referenced in the reports. 

26 Air Division Support - To provide 26 Air Division operations with a 
SAGE Master Tape configured to reflect the current Air Division environ- 
ment. This tape is regularly updated to reflect changes to local geogra- 
phy, telling capabilities, input sources such as long range radars, and 
other characteristics unique to 26 Air Division. 
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SAGE PROGRAMMING AGENCY TECHNICAL TASKS 


1. Requirements Analysis - to insure correct interpretation of require- 
ments for a program change, identify intra/inter system impact, and iden- 
tify a design for consideration. 

2. Design Development and Evaluation - to select and specify the design 
that will be implemented to meet Command requirements. 

3. Documentation - to record and disseminate information necessary for 
program design, testing, and updating operational specifications and user 
document s . 

4. Program Design - to develop program change specifications to satisfy 
operational design requirements. 

5. Program Coding - to add, change, or delete program instruction 
sequences and encoded parameters so that changed programs satisfy program 
change specifications. 

6. Communications Pool Generation (COMPOOL, dictionary ) - incorporate 
new or revised compool requirements. 

7. Master Tape Production - reassemble all systems using the new compool 
and load all programs on the newly assembled tape. 

8. System Change and Correction Monitoring - the analysis of present 
and future changes affecting the programs, equipment, and operational 
procedures . 

9. Operational Program Monitoring - providing quality control of the 
operational computer program by monitoring program change documents and 
implementing changes to maintain a high quality program system. 

10. S ystem Adaptation - insuring that the local operational program 
system reflects the current environment.. This includes data collection, 
calculation, coding, verification, and the writing and publication of 
required documentation. 

11. Local Change Activity - the design, coding, and testing of approved 
emergency changes, test changes, and other site-unique features loaded 
(or to be loaded) on the local program tapes. 

12. Tape Load - the mechanics of readying the computer program for 
local use to include accumulating and preparing the load inputs, key- 
punching, computer operation, and tape comparison/duplication. 

13. Test Preparation - the development of test inputs, checklists or 
event lists; the establishment of analysis methods and procedures; the 
planning and coordination of test activities with other agencies. 
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14. Test Conduct - the performance of functions which verify or check 
out the operational program systems, including manning of consoles, 
monitoring test progress, generation of outputs, and the collection of 
pre-planned data. 

15. Test Analysis - the reduction of test output data, verification 
of program quality, and documentation of test results. 

16. Version Turnover Documentation - the preparation and publication 
of information pertinent to the content and use of the new computer 
program version. 

17. Error Detection and Resolution - the recognition and categorizing 
of program problems including investigation, reporting, and problem 
resolution. This activity requires familiarization with the relation- 
ship of the program to associated equipment and related operational 
procedures . 

18. Technical Communications - the activities required for the inter- 
change of technical information including the production of formal 
documents, the planning and participation in meetings and workshops. 

19. Utility and Support Program Application - in depth knowledge and 
use of those programs necessary for performing program maintenance. 

20. Special Project Support - the application of programming skills 
to the development and implementation of special projects designed to 
improve air defense systems. 
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ORGANIZATIONAL DESCRIPTION 


The SAGE Programming Agency is organized under 26 DCS /Operations 
at Directorate level and is managed by a senior computer systems staff 
officer who directs and coordinates the varied work functions involved. 

Each systems analyst and programmer is assigned to one of the 
Divisions within the Directorate which has responsibility for a segment 
of the SAGE program system. Aircraft Control & Warning Technicians and 
computer operators are assigned to those functional areas which best 
use their combined operational and technical skills. 

Analysts and programmers are responsible for acquiring and main- 
taining current technical knowledge of operational specifications and 
program logic within their assigned functional area as well as a work- 
ing understanding of operational problems and procedures. 

Interlaced with the formal functional organization and crossing 
established organizational channels, a product oriented sub-organization 
exists. Each product (SAGE Program Change) authorized by ADC is assigned 
to a Product Coordinator in one of the functional Divisions. This analyst 
chairs an analysis team and manages the design and implementation of the 
assigned product throughout the production cycle of the change. The 
technical work involved in operational design and design implementation 
is accomplished primarily through this sub-organization of Product Coord- 
inators. Quality control of over-all production is accomplished by the 
Management Control Division which monitors the status of all products 
and verifies quality and reliability. 

Effective support of the SAGE system is provided through a coordi- 
nated team effort within the SAGE Programming Agency as w^ll as active 
liaison with operations and hardware maintenance personnel. Daily 
contact with programmers at all SAGE field sites insures that program 
problems are rapidly identified and resolved; timely preventative actions 
provide maximum program reliability. 
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ORGANIZATION SAGE PROGRAMMING AGENCY 
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SAGE PROGRAMMING AGENCY FUNCTIONS 


Management 

Control 
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Proficiency Evaluation 
Design Monitoring 
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Systems Testing 
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Data Reduction 
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General Item & Table Proc (GIANT) 
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Recording Method (NORM) 

SCORE 
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System 
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Interceptor Guidance 

BOMARC Guidance 

Air Defense Artillery 

Weapons Simulation 

Data Link 

Displays 

Switches 

Northern Tier Project (NOTIP) 


Surveillance 

Systems 

Division 


Telling 

Height 

Real Time Quality Control (RTQC) 

Radar Inputs 

Tracking 

Manual Inputs 

Identification 



Master Tape Assembly 

Geography 

COMPOOL 

Facility Programs 
S tar tover/ Switchover 
Program Control 
Reduction Systems Operation 
Tape Load 


Honeywell Programming 
Technical Library 
Document Production 
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OPERATIONAL DESIGN PROCESS 


SYSTEMS 

REQUIREMENTS 

ANALYSIS 


1. Define task: Feasibility, validity, operational advisability. 

2. Analysis Team Meeting or consultation with other designers/ 
programmers. 

3. Document all coordination and require Analysis Team Members to 
sign off report. 


SYSTEMS 

OPERATIONAL 

ANALYSIS 


1. Detailed examination of design requirements in terms of: 

a. Operational Requirements. 

b. Impact on Ops Specs. 

c. Impact on Program Systems Specs. 

2. During production of first draft of Analysis Documents, 
checklists/detailed document formats are used to insure that 
full coordination has occurred. 


DOCUMENT PRODUCTION 


1. Analysis Reports. 

2. Analysis Team Study Reports. 

3. Design Ghange Suggestions. 

4. Program Change Request. 

5. Program Design Change. 

6. Changes to official documents as a result of above. 
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PROGRAM DESIGN PROCESS 


PROGRAM DESIGN 


1. Program Design Specifications: 

a. Flow Charts o 

b. Prose Description. 

c. Identify System/ Program Interface, Document/Compool/ 
Initial Data Changes. 

2. Review of Design Specifications by Product Coordinators, Divi- 
sion Chief, and Designers in other affected areas: 

a. Are requirements being met? 

b. Are Design Specifications detailed enough to permit 
coding by any other programmer? 

c. Is design rational cost effective? 

Programming effort - Space - Program Operating Time. 


PROGRAM CODING AND 
SUBPROGRAM TESTING 


1. Code from Design Specifications. 

2. Produce a Test Plan: 

a. Inputs/Outputs required to test each subprogram. 

b. Test Tool available — are new tools required? 

c. Define Initial Conditions. 

d. Recording requirements. 

e. Specify required environment and test methods. 


PRODUGT TESTING 


1. Subprogram Testing by Programmer. 

2. Assembly Testing by Product Coordinator. 

3. System Testing by Version Coordinator. 
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VERSION PRODUCTION PROCESS 



SYSTEMS TESTING 


1*. Allocation o£ new compool. 

2. Reassemble all systems using 
new compool. 

3. Re-load Facility Programs, 
Symbolic Correctors, and 
Compool. 

4. Overload base modifications 
of operations programs. 

5. Load Symbolic Corrector 
History. 

6. Load Initial Data. 

7. Verify Base Maintenance 
Master. 

8. Load Initial Data for Test 
Environment. 

9. Cycle check Base Mainte- 
nance Master. 


1. Receipt and initial check 
of each new product. 

2. Prepare Product Test Plan. 

3. Load Products weekly. 

4. Perform Product Tests until 
Product Acceptance: 

a. On-Line Printout/ 
Desk Check. 

b. Blue Room Tests IAW 
Test Plan. 

c. Open Problem Reports 


Integrated Systems Test 

Procedures: 

1. Update ISTP Documents. 

2. Develop Special Tests. 

3. Prepare Test Tools: 

a. UNISIM Tapes . 

b. Duplex Sets of 
SIM Tapes and 
Duplex Telling 
Tools. 

c. SIM Tapes to 
generate MORT 
Recording req's 
to analyze and 
test Utility 
and Support 
programs . 

d. ROSE: Replay 
for Over-all 
System Eval. ; 
enables repeti- 
tion of Identical 
Test Conditions 
for problem 
analysis. 

4. Prepare Test Scripts. 

5. Run Tests. 



COMPUTER SYSTEMS ANALYST 


A. Job Descriptio n. Designs, develops, tests and/or maintains computer 
programs and/or program systems to satisfy specific operational require- 
ments . 

B. Major Duties ; 

1. Designs computer programs and/or program systems to meet operational 
requirements by performing such duties as meeting with ADC representatives 
and in-house users to establish and clarify program specifications, deter- 
mining and recommending appropriate problem-solving methods and means to 
accomplish desired objectives. 

2. Develops computer programs from approved design specifications by 
preparing detailed flow diagrams, writing computer language instructions, 
devising appropriate tests for debugging and verifying programs, and 
ensuring that the generated output conforms to design criteria and speci- 
fications . 

3. Maintains assigned programs by analyzing generated output and/or 
error reports to detect, program deficiencies, determining and developing 
appropriate error corrections, testing corrections to verify their accur- 
acy, and incorporating subsequent modifications into original programs to 
produce updated versions. 

4. Designs, implements, analyzes, and supervises large-scale system 
tests to verify that the computer program system operates under a wide 
variety of conditions. 

5. Responsible for preparing such documentation as design specifica- 
tions, program descriptions, operating guides, and users’ manuals to assure 
that the objectives, instructions, and unique features of assigned pro- 
grams are communicated clearly and effectively to intended audiences. 

6. Performs evaluations in the development, implementation, ar.d 
maintenance of assigned programs including assessing existing software 
of potential application, reviewing completed programs for possible 
refinements, investigating the appropriateness of design change suggestions, 
verifying that required modifications have been tested and integrated, and 
ensuring that revisions have been made to affected documentation. 

7. Maintains and applies a working knowledge of all equipment and 
program interfaces to facilitate the testing and integration of assigned 
programs , 

8. Determines and establishes realistic schedules to meet established 
completion dates. Monitors and evaluates the progress of assigned projects, 
and coordinates with external and internal users/operational representatives 
to ensure an effective, reliable end product. 
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COMPUTER SYSTEMS PROGRAMMING OFFICER 


A. Job Description . Performs beginning professional programming assign- 
ments under the supervision and/or guidance of higher level programming 
personnel. 

B. Major Duties ; 

1. Designs computer programs under the general direction of super- 
visors or more senior programming personnel to establish and clarify pro- 
gram specifications, determine and recommend appropriate problem-solving 
methods and means to accomplish desired objectives. 

2. Develops computer programs from approved design specifications by 
preparing detailed flow diagrams, writing computer language instructions, 
defining test requirements, and ensuring that the generated output 
conforms to design criteria and specifications. 

3. Maintains assigned programs by analyzing generated output and/or 
error reports to detect program deficiencies, determining and developing 
appropriate error corrections, testing corrections to verify their accuracy, 
and incorporating subsequent modifications into original programs to 
produce updated versions. 

4. Designs, implements, and analyzes tests for computer programs to 
ensure that new programs of modifications to existing programs conform 
to design specifications. 

5. Produces and maintains documentation pertaining to specifically 
assigned programs to assure that their objectives, instructions, and 
unique features are communicated clearly and effectively to intended 
audiences. 

6. Consults with supervisors and similar level programmers concerning 
problems related to assigned areas, changes which affect areas beyond 
immediate, assignments, and various programming tasks as required to affect 
timely completion of assignments. 
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DEPARTMENT OF THE AIR FORCE 26DOS 01 55-3 

Headquarters, 26 Air Division (ADC) 

Luke Air Force Base, Arizona 85301 10 November 1971 

Operations 

CODING CONVENTIONS & RESTRICTIONS 

To standardize the assignment and control of final letter identifiers 
for program correctors. 


1. Responsibility . 26D0S personnel will comply with the following 
coding conventions and restrictions in the generation of programs and/ 
or program coding for the SUOP system. The responsible division chief 
may authorize deviation, after coordination with DOSM. Programs or 
coding which are now in violation of the procedure specified in this 
01 are to be corrected as the programs are upmoded, and/or a new corn- 
pool generated. 

2. References : 

a. TM 3010, FAST Complex User Manual. 

b. TM 3233, COSEAL Utility System Manual. 

3. Coding Conventions : 

a. Programs . All programs will be identified by a three (3) letter 
symbolic name; i.e., TRK, W0M. 

b. Program Mod Designators . The program mod designators will be as 
follows : 


(1) SUOP Operational Programs . The mod designators for these 

programs will consist of two (2) letters. The first letter will denote 
the type of program; i.e., DC = D, FAST = F, etc. The second letter 

denotes the mod update identification; i.e., SIS DE, FCP FC. 

(2) SUOP Pseudo Programs (Adaptations) . The mod designator 
procedures are: 

(a) Operations Tapes (Future and Current) . The mod desig- 
nator will consist of a digit and a letter. The digit indicates the 
version applicability and the letter denotes the sequence alphabetical 
order of the modifications. The alphabetical designator will be changed 
each time there is a corrector deck submitted; i.e., CXS IC = program 
CXS , Version 51 applicability, the third change. 


This 01 supersedes 26DOS 01 55-3, 19 Jan 71 
OPR: DOSM 
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(b). TNR , 25 and 75 Air Div Tapes . The mod designator for 
these tapes will consist of two characters. The first being a unique 
designator; T = TNR, X = 25 Air Div, and F = 75 Air Div; the second will 
identify the modification using the letters A through Z and returning to 
A. , i 

Note : DOSC will maintain a log of all pseudo programs and their mod 
designators. This log will be made available on request and it will con- 
tain listings for both the current and future versions of all four (4) 
types of configurations; Ops, TNR, 25, and 75 Air Div. 

c. Tables . All tables will be identified by a three (3) letter 
symbolic name and a digit; i.e., ARM0, TTY0. 

d. Items . Items will be identified by a four (4) letter symbolic 
name; i.e., TIDY , ARDI, etc. 

e. Location Identifiers : 

(1) Within main body of program, locations will be identified 
by two (2) digits and a letter; i.e., 10A, 35N, etc. 

(2) Final address or corrector pool locations will be identified 
by two (2) digits and two (2) letters; i.e., 10AB, 35NC, etc. 

4. Coding Restrictions are as follows : 

a. Tags will be maintained in an alpha-numberic sequence in order 
to facilitate troubleshooting and program correction. 

b. The number of registers between program tags will be limited to 
less than one hundred (100) to facilitate program modification. 

c. Program constants will normally be located in the 60 region of 
the programs. 

d. Regions within a program will be referenced to by the two (2) 
digit identifier; i.e,, 21 region, 35 region. 

e. Areas of a program are defined as two (2) digits and a letter; 
i.e., 15B area, 42A area. 

f. Whenever possible, program adaptation will be contained in a 
pseudo program. All references should be made to compool- defined items 
and table tags. 

g. Macro and Command instructions may not be utilized for opera- 
tional programming. 

h. CPO Tags . - Compool overrides (CPOs) are not to be used in pro- 
gram assemblies. 
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i. Reference to Compool . Reference to compool- defined items is 
to be in symbolic form only; e.g., P0S31 TIDY; not FCL 12. 

j. I/O Interrupt . An "add class" instruction must not be followed 
by "STA" or "STAA" instructions because the "A" register may not be 
cleared due to the I/O Interrupt feature. 

k. The pseudo instruction "PGM" will appear in the second register 
of all programs. 

l. An extraneous exit from a TTB instruction should exit to an 
address as if a legal value had been found. 

m. SYC coding over deleted areas should be avoided because it 
severely decreases the effectiveness of automatic updating tools. 

5. Symbolic Corrector Card and Deck Conventions . The following proce- 
dures will be adhered to by SPA personnel when generating corrector 
decks for load to the SUOP and RUN systems. 

a. Card column information for program data on SYC correctors is 
contained in paragraph 1.2.1, Chapter 2, FAST User Manual. 

b. Card column information for program data on COMPOOL corrector 
cards is contained in paragraph 1.2.2, Chapter 2, FAST User Manual. 

c. Card column information for program data on ETS corrector cards 
is contained in paragraph 2.3, Chapter 2, FAST User Manual. 

d. Card column information for program data on MOR0 card is con- 
tained in Volume 2, Chapter 4, COSEAL Manual. 

e. In order to assist in tape load and card handling procedures, 
the corrector decks will contain the following additional information: 

(1) SYC Card Columns : 

0001 556 77 7 8 

1587 893 01 2 0 

AAA BB CCCC DDD EEEEEEEfG — - 

AAA = Three (3) character program ident. 

BB = Two (2) character program mod designator for correctors 
to operational programs only. Pseudo adaptation program 
corrector need not have these designators punched. 

CCCC = Four (4) letter SUOP file ident. Applicable to IDT cards only . 
17,58,72,80 = FAST Manual Content. 

DDD = Three (3) digit sequence number, starting at 000 on the IDT 
card and numbered consecutively through and including the 
END card. 

EEEEEEE = Seven (7) character corrector ident. 
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f = Modification/Reissue letter or digit. 

G = Modification letter to a dash one (-1). 

Sample idents in card columns 63 through 71: 


PCs = 06Pc051, 22PC071A, 07PC0161. 
MCs - 66MC059, 69MC010A, 66MC0521. 
SPCs = SPC2555, SPC2599A, SPC26001A. 
ARs * 22AR001 , 07AR002A, 20AR0011A. 


NMs 

i = 07NM001. 





PD 

= 07PD001. 





Sample 

Corrector Deck: 





0 0 

0 12 

3 4 

5 

6 

7 7 

1 5 

8 7 5 

6 0 

9 

3 

2 7 

SKD DB 

IPGD IDT 

SKD DB 

000 

07PC061 


SKD DB 

C BPX 

10BB 

001 

07PC061 

10B +01 

SKD DB 

BPX 

10BC 

002 

07PC061 


SKD DB 

END 


003 

07PC061 



Note : All program IDT cards will contain the SUOP file ident in card 
columns 8-11 and the program mod designator in card columns 40-41. 


0 

— t w — 

(2) ETS Card Columns: 

1 

55 

6 

7 

7 

7 

8 

7 

67 

5 

2 

5 

9 

AAAA 


BBBBBBBBB 

C 

DDDDEE 


AAAA * Four (4) letter SUOP file ident. All cards. 

17/56 * FAST Manual Content. 

BBBBBBBBB = Same as columns 64 through 71 of SYC correctors. 

C * Either P for production release values or S for site-unique 
values. 

DDDD = Master sequence number received from DOSC. 

EE s Deck sequence number. 

(3) C0MP00L Correctors will use the same additional informa- 
tion card format as for SYC cards. 


(4) MQR0 i 


0 

0 

0-1 

1 

1 

1 

4 

4-4 

5- 5 

5-6 

1 

6 

8 0 

2 

6 

7 

4 

7-9 

4 7 

9 2 

AAAAAA 

BBB 

CCCCC 



DDD 

EEEE 

FFFF 
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AAAAAA = 
BBB = 

ccccc = 
*17/44 = 
DDD = 
EEEE = 
FFFF = 


MOR0 Identifier; i.e., MOR0 51. 

Sequence number. 

Compool and mod identifier. 

Programmer supplied values per COSEAL, Volume 2, Chapter 4. 
Unique entry identifier (octal value). 

Indexing value (optional decimal value). 

Number of registers to be recorded (optional decimal value). 


*These will be the only values supplied by the programmer. All other 
card columns will be assigned by DOSU. 


HERBERT J. SUSKIN, Lt Colonel, USAF 
Director of SAGE Programming Agency 
DCS /Operations 
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DEPARTMENT OF THE AIR FORCE 26DOS 01 55-6 

Headquarters, 26 Air Division (ADC) 

Luke Air Force Base, Arizona 85301 11 November 1971 

Operations 

ADAPTATIONS AND INITIAL DATA CHANGE PROCEDURES 

(66/69 MCs) 

Establishes the procedures for updating the adaptation geography, and 
initial conditions for the 26 NORAD Region and/or the Test NORAD Region 
(TNR) environments. 


1 . References : 

a. TM 3255/XXX - Analytical Compendium, Volumes 1, 2, and 3. 

b. 26DQS 01 55-3, Coding Conventions and Restrictions. 

c. 26DQS 01 55-8, Program Errors. 

d. 26D0S 01 55-10, SU0P Master Tapes. 

2. Responsibility . 26D0S personnel will comply with the following 
procedures when generating changes to either the Active Air or Test 
environments . 

3 . Terms Explained : 

a. Test N0RAD Region (TNR). A SU0P tape containing the mythical/ 
live environment required by the SAGE Programming Agency (SPA) in order 
to develop, test, and evaluate the new SAGE products/versions. 

b. 66MC - A document produced in TPR format issued in support of 
changes to the Region's Active Air Defense (AAD) adaptation, geography, 
and initial conditions and when completely compatible, card for card, 
with the TNR data base will be authorized for load to the TNR tape. 

c. 69MC - A document produced in TPR format issued in support of 
changes in the TNR environment , adaptation, geography and initial 
conditions or to load AAD changes which cannot be loaded on a card- for - 
card basis because of an effect on the mythical environment. 

4. Procedures . When a requirement exists to change either the AAD or 
TNR environments, the following procedures apply: 


Supersedes 260PM 01 55-6, 21 Oct 69 
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a ^ The programmer will review the requirement, determine the type 
of change required (a 66MC , 69MC, or possibly both), and obtain the 
appropriate number (s) from DOSM. 

b. If a PIR was the basis for the change, the programmer will close 
it by indicating that the problem was due to an adaptation error, giving 
the 66/69 number, per reference "c." 

c. The programmer will develop, test, and evaluate the correctors. 
The provisions of references "a" and "b" will be adhered to in the pro- 
duction of the card decks . 

d. When the programmer is satisfied that the correctors operate as 
required, he will produce and submit a final draft of the MC, through 
his division chief, to DOS for typing. The MCs will be in TPR format 
and contain the following: 


" 1 . 

Subject/Title: 


2. 

System/Version/Program: 


3. 

Reference: 


4. 

Descriptive Data: 


5. 

Document Changes (to include, 
changes to the TM-820 series 

in exact format and content, 
documents) : 

6. 

Miscellaneous Comments: 


7. 

Program Data:" 


When 

66/69 MCs are to be loaded to 

both the current and the 


future versions, the programmer will submit two corrector decks and two 
load requests to DOSM. 

f. When the required change is common to both the current and future 
versions and the corrector deck is not completely compatible with the 
future version, due to NMs or PDCs, a dash one (-1) change will be gener- 
ated and submitted by the programmer. 

g. The programmer will have DOSC produce the necessary tape load 
request(s) and five (5) copies of a multi listing. He will complete the 
tape load request(s), have it signed by his division chief, and submit 

it together with the corrector deck(s) to DOSM, where they will be handled 
as outlined in reference "d." He will deliver the five copies of the 
multi listing to DOS, where they will be attached to the main body of the 
MC. 
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h. When unclassified , DOS will produce five copies of the MC, 
attaching the multi listing. When completed, DOS will notify the 
programme*- that the MC is ready for proofreading. 

i. When classified , DOS will produce three copies of the MC, 
attaching the multi listing. When completed, DOS will notify the 
programmer that the MC is available for proofreading. 

j. When the programmer is satisfied that the MC is correct, he 
will forward the MC to DOSM for coordination and distribution. If 
classified, he will forward a Document Coordination Sheet (26AD Form 
70) to DOS and DOSM for coordination, to DOSC in order for them to 
extract the classified TM-820 changes, and to the other division 
chiefs for their information. 

5 . Pi s tr ibution : 


a. When unclassified , five copies will be distributed as follows: 

(1) The original to the issuing programmer for the Area Note- 
book. 


(2) One copy to DOSM for inclusion into the appropriate Ver- 
sion Description (VD) and then for file. 

(3) One copy to DOS for his information and then for the DOS 
read file. 

(4) One copy each to the 2 6 NR BUIC sites. 

b. When classified , three copies will be distributed as follows: 

(1) The original filed in the DOS safe. A document coordina- 
tion will be circulated through DOS, DOSM, and the other division 
chiefs for their information. 


(2) One copy each to the 26NR BUIC sites. 
6. Attachments: 


a. Attachment 1 contains a listing of all the SUOP adaptation 
programs and the responsible divisions. 


b. Attachment 2 contains a listing of all the SUOP initial condi- 
tions, table blocks, and the responsible divisions. Reference "a' 1 will 
be used to determine whether an item is site unique, production release, 
optional, and the authorized values. 




HERBERT J. SUSKIN, Lt Colonel, USAF 
Director of SAGE Programming Agency 
DCS/Operations 
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1. Adaptation Programs 

2. Initial Conditions Assignments 
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ADAPTATION PROGRAMS AND RESPONSIBLE DIVISION 


Program 

DOS Divi 

AAA 

DOSW 

APP 

DOSC 

BAP 

DOSW 

BUG (50 Region) 

DOSW 

BUK 

DOSS 

GAP 

DOSC 

CXA 

DOSS 

CXS 

DOSS 

DAD 

DOSW 

FLO (50 Region) 

DOSS 

GFR 

DOSS 

GUM 

DOSW 

GUV 

DOSS 

LUV 

DOSS 

MAG 

DOSW 

MHA 

DOSS 

MIA 

DOSS 

MOM 

DOSS 

RCP 

DOSW 

SAD 

DOSW 

SMB (50 Region) 

DOSW 

SSS 

DOSW 

TEE (50 Region) 

DOSS 

TOT 

DOSS 

TRN (50 Region) 

DOSS 

TRU 

DOSS 

WAM 

DOSW 

YAK 

DOSW 

YXN 

DOSS 


Attachment I 
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ADAPTATION PROGRAMS AND RESPONSIBLE DIVISION 


Program 

DOS Division 

AAA 

DOSW 

APP ; 

DOSC 

BAP 

DOSW 

BUG (50 Region) 

DOSW 

BUK 

DOSS 

GAP 

DOSC 

CXA 

DOSS 

CXS 

DOSS 

DAD 

DOSW 

FLO (50 Region) 

DOSS 

GFR 

DOSS 

GUM 

DOSW 

GUV 

DOSS 

LUV 

DOSS 

MAG 

DOSW 

MHA 

DOSS 

MIA 

DOSS 

MOM 

DOSS 

RCP 

DOSW 

SAD 

DOSW 

SMB (50 Region) 

DOSW 

SSS 

DOSW 

TEE (50 Region) 

DOSS 

TOT 

DOSS 

TRN (50 Region) 

DOSS 

TRU 

DOSS 

WAM 

DOSW 

YAK 

DOSW 

YXN 

DOSS 


Attachment 1 
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h. When unclassified , DOS will produce five copies of the MC, 
attaching the multi listing. When completed, DOS will notify the 
programmer that the MC is ready for proofreading. 

i. When classified , DOS will produce three copies of the MC, 
attaching the multi listing. When completed, DOS will notify the 
programmer that the MC is available for proofreading. 

j. When the programmer is satisfied that the MC is correct, he 
will forward the MC to DOSM for coordination and distribution. If 
classified, he will forward a Document Coordination Sheet (26AD Form 
70) to DOS and DOSM for coordination, to DO SC in order for them to 
extract the classified TM-820 changes, and to the other division 
chiefs for their information. 

5. Distribution : 

a. When unclassified , five copies will be distributed as follows: 

(1) The original to the issuing programmer for the Area Note- 
book. 

(2) One copy to DOSM for inclusion into the appropriate Ver- 
sion Description (VD) and then for file. 

(3) One copy to DOS for his information and then for the DOS 
read file. 

(4) One copy each to the 26NR BUIC sites. 

b. When classified , three copies will be distributed as follows: 

(1) The original filed in the DOS safe. A document coordina- 
tion will be circulated through DOS, DOSM, and the other division 
chiefs for their information. 

(2) One copy each to the 26NR BUIC sites. 

6 . Attachments : 

a. Attachment 1 contains a listing of all the SUOP adaptation 
programs and the responsible divisions. 

b. Attachment 2 contains a listing of all the SUOP initial condi- 
tions, table blocks, and the responsible divisions. Reference "a 11 will 
be used to determine whether an item is site unique, production release, 


2 Atch 

1. Adaptation Programs 

2. Initial Conditions Assignments 


optional, and the authorized values. 


HERBERT J. SUSKIN, Lt Colonel, USAF 
Director of SAGE Programming Agency 
DCS/Operations 
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DEPARTMENT OF THE AIR FORCE 26DOS 01 55-7 

Headquarters 26 Air Division (ADC) 

Luke Air Fcrrce Base, Arizona 85301 7 December 1971 

i 

v Operat ions 

CODING SHEETS AND KEYPUNCH PROCEDURES 

Establishes the procedures for DOS progrannners to have cards (AF Form 
1500) keypunched and standardize the numbers, letters, and special 
characters to be used. 


1. General. LGK-MR has indicated that they will assist in keypunching 
cards for DOS programmers on a work load-permitting basis. 

2. Responsibility . DOS personnel will comply with the following pro- 
cedures when requiring assistance in keypunching cards. 

3. Procedures : 

a. Individual programmers will: 

(1) Fill out the programming coding sheet (ADC Form 298), 
insuring that all numbers, letters, and special characters adhere to 
Attachment 1. 

(2) Turn in the coding sheet to NCOIC, DOS. 

b. NCOIC will: 

(1) Have the coding sheet delivered to NCOIC, LGK-MR, in Build- 
ing 241 on base. 

(2) When notified that the cards are completed, have them picked 
up and deliver both the coding sheet and cards to the H-200 operator. 

c. H-200 operator will: 

Produce an 80/80 of the card deck and notify the programmer that 
his coding sheets, cards, and 80/80 are available for pick up. 

HERBERT J. SUSKIN, Lt Colonel, USAF 1 Atch 

Director of SAGE Programming Agency , Coding Symbols 
DCS /Operat ions 
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EXAMPLE CODING SHEE7 MARKINGS 
Letters 

ABCDE FGHI JKL 


MNOPQRSTlli/WX 


Y Z 


Numbers 

1234 5 6789 / 


Symbols 
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DEPARTMENT OF THE AIR FORCE 
Headquarters, 26th Air Division (ADC) 

Luke Air Force Base, Arizona 85301 9 November 1971 

Operations 

PROGRAM ERRORS 

Establishes procedures for reporting, statusing, and correcting any sus- 
pected program errors. 


1. Responsibility . DOS personnel charged with program development, 
testing, and maintenance are responsible to insure they comply with 
the procedures contained in this 01 when handling Program Incident 
Reports (PIRs) , Program Problem Reports (PRs), Program Error Corrections 
(PCs). 

2. Procedures: 


a. PIRs . This type of report may be initiated by anyone within the 
26 Air Division who suspects there might be or has knowledge of a pro- 
gram error. The error will be opened by completing one copy of the PIR 
Form (ADC Form 119) and forwarding it to DOSM. It is emphasized that 
the more information supplied the programmer the easier it becomes to 
locate, identify, and correct the problem. The PIR, when complete, 
should include as much of the following information as possible: 

Designator of tape version; i.e., P50G. 

A statement of the problem including all unusual incidents lead- 
ing up to it. 

Both the frame number and zulu time/date. 

The computer in use at the time (A side or B side) . 

Whether Live, SIM Over Live, SSTM, Duplex, etc. 

Call signs/ track numbers and whether or not the "Record Track 
Action" was taken. 

(1) Actions: 


(a) DOSM will, on receipt, assign a PIR number. If the 
PIR is reported against the current official operations tape, a "C" PIR 
number will be assigned. If reported against a version undergoing pre- 
release testing (Future Version), an "F" PIR number will be assigned. 
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JL. C-PIRs will be closed only by one of the following: 

i 

a. PIR withdrawn due to a misinterpretation of the 
Operational Specifications or unable to duplicate. Possible operator error. 

_b. PIR closed, equipment malfunction, Equipment 
Status Report (ESR) number xxxx opened. 

c. PIR closed, program error, 07PRXXX, 66MCXXX, 

or 69MGXXX opened. 

2. F-PIRs will be closed only by one of the following: 

a. PIR withdrawn due to a misinterpretation of the 
Operational Specifications or unable to duplicate. Possible operator error. 

_b. PIR closed, equipment malfunction. Equipment 
Status Report 9ESR) number xxxx opened. 

£. PIR closed, program error. One of the following 
will be issued: 06PC, 66MC, or 69MC. When the 06PC is not available prior 
to the version release date, an 06PR will be produced and will be distributed 
as part of the release package. 

d. PIR closed, program error, but because the product 
has not yet been physically loaded onto the tape and the program specifica- 
tion has not yet been published, the Product Coordinator can correct the 
error and reissue the deck for load. In addition, the program specifications 
will be changed to reflect the correct coding. 

(b) DOSM will type the report in four (4) copies, and distribute 

as follows: 

_1. Two copies to the responsible division chief. 

2. One copy retained by DOSM. 

.3. One copy for the Senior Director's Status Log. 

(c) DOSM will determine the division chief responsible for 
the area in which the error is located and forward the PIR to him. 

(d) Division chiefs will have three (3) working days to evalu- 
ate the report in order to determine whether the PIR is: 

.1. Valid program problem - He will have an official 06/07 
PR, 66 MC, or 69 MC opened. 

2. Equipment malfunction - He will notify the Maintenance 
Control Section (751) and obtain an ESR number. 
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3. Due to a misinterpretation of the Operational Speci- 
fications; so state and status it closed. 

4. If additional time is required to close a PIR because 
of its complexities, or because we are unable to duplicate, or because other 
higher priority projects prevent us from working the suspected problem, 
division chief will so indicate on the PIR with the type of action to be 
taken and forward to DOSM. 

(e) After the evaluation, division chiefs will return one 
copy of the PIR to DOSM indicating the actions and findings. 

(f) When a completed C-PIR form is returned to DOSM, the 
comments will be typed onto the originator's copy and the file copy. The 
originator's copy will then be returned to him. The copy received from 
the division chief will be filed in the DOSM file, with the other copy 
being forwarded for the Senior Director's Status Log. 

(g) When a completed F-PIR form is received, the procedures 
in paragraph 2a(l)(f), above, will apply except an additional copy will 
be made and forwarded to Director, DOS, for informational purposes. 

(h) F-PIRs which are resolved prior to release date will be 
overloaded on the release tape and the 06-PC will be part of the release 
package. (See paragraph 2c(2).) 

(i) F-PIRs which are unresolved on release of a new version 
will be prepared in 06-PR format and distributed to the field as part of 
Version Release Letter. They will be closed by issuing 06-PCs using the 
same procedure in paragraph 2c(l), below. 

b. PRs . Reports of this type may originate from field units and as 
a result of internal PIR action. The procedures outlined herein will be 
employed when processing PRs. 

(1) PRs originating from the field. - The procedures to be used 
by the field sites are covered in the appropriate ADC Manuals. 

(a) On receipt, DOS will insure that the PR is in sufficient 
quantities (4 copies) and distribute as follows: 

1.. One (1) copy to the responsible programmer through 
his division chief. 

2. One (1) copy to DOSM. 

3. One (1) copy to Director, DOS, and then for division 

chiefs' read file. 

4. One (1) copy for Senior Director's Status Log. 
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(b) DOSM will maintain a Master PR Status Board and will 
generate the Weekly Problem Summary Report. The report will list all 
open problems, problems closed and transmitted to the field, problems 
closed and not transmitted to the field. The report will also show 
any changes in status of previously reported problems. 

(c) The responsible division chief will status the prob- 
lem and forward the PR to the programmer (s) responsible for the system/ 
program. 


(d) Complying with the priority scheme contained in the 
appropriate ADC Manuals, division chiefs in conjunction with their pro- 
grammers will decide how the PR is to be processed. 

(e) Division chiefs will display the PR on their Weekly 
Status Slides, noting any change in status and/or progress in the clos- 
ing of the PR. 

(f) The responsible programmer will resolve the PR as soon 
as possible by issuing a PC. Requests for assistance for corrector test- 
ing will be made through their division chief to DOSM. 

(2) PRs resulting from internal "C-PIR" status: 

(a) When the problem is a result of a program error, the 
responsible programmer will get a PR number from DOSM and generate a PR 
in final draft form. Submit the draft to DOS for typing. 

(b) DOS will prepare the PR in five (5) copies for distri- 
bution as follows: 


1. Two (2) copies to Communications Center; one (1) 
will be returned with date/ time group stamped on the form. 

2. One (1) copy to DOSM. 

3. One (1) copy to Director of DOS for informational 
purposes and then to division chiefs' read file. 

4. One (1) copy to the Senior Director's Status Log. 

(c) The responsible programmer will proofread the completed 
PR, Insuring accuracy and completeness. Division chiefs will sign as 
releasers. The PR will then be carried to DOSM for coordination. 

(d) DOSM will pull the last three (3) copies and make dlstri 
button as outlined in paragraph 2b(2)(b), above. 
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(e) The responsible programmer will then handcarry the 
original and one (1) copy to the Communications Center where they will 
be stamped with the date and time of receipt. The original will be 
retained by the Communications Center and the programmer will file his 
copy in his Area Notebook. 

(f) DOSM will maintain a Master Version Problem Status 
Board and will insure the PR is included in the Weekly Status Report. 

(g) Division chiefs will display the PR on their Weekly 
Status Slides, noting any change in status and/or progress in the clos- 
ing of the PR. 

(h) The responsible programmer will resolve the PR as 
soon as possible by issuing a PC. Requests for assistance for corrector 
testing will be made through division chiefs to DOSM. 


c. PCs . Program Correctors will be generated to close 07-PRs, 
field-generated PRs, and F-PIRs. These correctors will be issued by 
complying with the following procedures: 


(1) 07-PCs and Correctors for field-generated PRs: 

(a) The responsible programmer will prepare the main body 
of TPR-PC in final draft form and submit to DOS for typing through his 
division chief. 

(b) To produce the listing of the coding, the programmer 
will deliver the card deck to DOSC and make a request for tape load and 
four (4) copies of a multi. He will deliver the multi listing to DOS, 
where they will be attached to the main body of the PC. The tape load 
request and card deck will be turned over to DOSM. 


(c) DOS will prepare the PC in five (5) copies and notify 
the programmer that the PC is ready for proofreading. 


(d) After proofreading, the responsible programmer will 
have his division chief sign as releaser and bring all copies of the PC 
to DOSM for coordination. 

(e) Distribution for PCs is as follows: 


Center . 


JL. The original with attachment for Communications 


2 . One (1) copy including attachment for the programmer. 

3. One (1) copy including attachment for DOSM. 
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4. One (1) copy for the Senior Director's Status Log - 

no attachment. 

J5. One (1) copy with attachment for Director of DOS, 
and then for the division chiefs' read file. 

(f) DOSM will initial the coordination copy and pull the 
last two (2) copies for distribution as outlined in paragraph 2c(l)(e), 
above . 


(g) The programmer will then handcarry the original and 
two (2) copies including attachment to the Communications Center where 
they will be stamped with date and time of receipt. The original will 
be retained by the Communications Center and the programmer will keep 
one for his Area Notebook and forward the other to DOSM for the Master 
File. 


(h) The Communications Center will produce punched tape 
and a hard copy. of the PC and notify the programmer that the PC message 
is ready for proofreading. 

(i) The programmer will insure that the PC message is 
correct and authorize its transmission. 

(j) When a problem is common to both the current and future 
versions and it is determined by the issuing programmer that the 07 -PC is 
completely compatible with the future version; i.e., the exact card con- 
tent can be loaded on the future tape, a duplicate card deck and load 
request will be produced and delivered to DOSM by the programmer. DOSM 
will verify the corrector for version compatibility and then release the 
future version load request to DOSC. 

(k) When a problem is common to both the current and future 
versions and the corrector deck is not completely compatible with the 
future version a -1 change will be issued (see paragraph 2e below). 

(l) Card format for the correctors is contained in 26DOS 

OX 55-3. 

(m) Procedures for handling changes to these PCs are speci- 
fied in paragraph 2f below. 

(2) 06-PCs Issued Prior to Version Release Date : 

(a) The responsible programmer will prepare the main body 
TPR-PC in final draft form, and submit to DOS for typing through his 
division chief. 
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(b) To produce the corrector listing, the programmer wilj. 
deliver the corrector deck to DOSC and make a request for a tape load 
request and nine (9) copies of a multi. The load request and the card 
deck will be submitted to DOSM for testing. All card decks will be in 
the format outlined in Attachment 1. The multi listings will be turned 
over to DOS, where they will be attached to the main body of the PC. 

(c) DOS will produce the PC in ten (10) copies, staple 
the attachment to each, and notify the programmer that the PC is availa- 
ble for proofreading. 

(d) When the programmer is satisfied that the PC is cor- 
rect, he will distribute as follows: 

JL . One (1) to Director of DOS and then for file in 

the Master File. 

2 . One (1) for Senior Director's Status Log (no 

attachment) . 

3. One (1) for the programmer's file. 

4. One (1) for DOSM. 

5. Six (6) copies for DOSC file; these will be made 
part of the Release Package. 

(e) DOSM will authorize the overload of PC by submitting 
the load request to DOSC. This will be accomplished after the PC is 
merged into the version testing schedule and verified. 

(f) Procedures for handling changes to these PCs are speci- 
fied in paragraph 2f below. 

(3) 06-PCs issued after release date. - The procedures for 07-PCs 
apply. (See paragraph 2c(l), above.) 

e. -Is, Cards Issued to Update Correctors to Insure Version Compati- 
bility . When correctors issued for a current version are not completely 
compatible with the future version, due to differences in program mods 
between the two tapes, a modified corrector deck will be produced for the 
future version. The procedures are: 

(1) The programmer will produce the modified corrector deck. 

The card columns 63 through 69 will contain the same abbreviated product 
designator as the original deck, but the card column 70 will contain the 
digit 1. 
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(2) The basic document will contain a statement in the comment 
section, indicating that a -1 is required. 

(3) A load request, corrector deck, and three copies of a multi 
listing will be produced and delivered to DOSM by the programmer. 

(4) After the deck has been verified for version compatibility, 
the load request will be submitted to DOSC, and the three (3) copies of 
the multi listing distributed, as outlined below, and attached to the 
basic document. 

(a) One copy to DOS for the Master File. 

(b) One copy to the programmer . 

(c) One copy to DOSM. 


f. Errors . Errors or oversight in any of the products of this 01 
will be closed by the programmer issuing changes to the basic document. 
These changes will be identified by the corrector deck containing a 
letter in card column 70. The first change issued will be identified 
as the "A" change and each succeeding change will be identified by the 
next alphabetical letter. The same type of TPR document issued in the 
base document will be produced for this type of change. The corrector 
listing need only to consist of the required cards; the unaffected 
cards of the base product need not be modified to reflect the change 
identifier. 




HERBERT J. SUSKIN, Lt Colonel, USAF 
Director of SAGE Programming Agency 
DCS /Operations 



DEPARTMENT OF THE AIR FORCE 
Headquarters, 26th Air Division (ADC) 

Luke Air Force Base, Arizona 85301 

Operations 

SUOP MASTER TAPES 

This Operating Instruction establishes the procedures and practices for 
the maintenance of the SUOP Master Tapes, tape designators, tape content, 
tapeloads, and tape slot assignments. 

1 • References : 

a. 26DOS 01 55-3, Coding Conventions and Restrictions. 

b. 26DOS 01 55-8, Program Errors. 

c. 26DOS 01 55-12, Computer Program Testing. 

d. Appropriate ADC Manuals 55-XX. 

2. Res ponsibility . SAGE Programming Agency personnel will comply with the 
provisions of this Operating Instruction when producing SUOP Masters, sub- 
mitting items for load, slotting tapes, generating version descriptions and 
submitting request for equipment changes. 

3 . Terms Explained : 

a. "Prpduct," for this 01, is defined as any SPC, AR, NM, and PDC which 
is being produced by the SPA. 

b. "Correctors , 11 for this 01, is defined as any PC or MC which will be 
or has been issued by the SPA. 

c. "Items," for this 01, is defined as the combined form of both "a" 
and "b" above. 

d. Job Sheet - a work sheet sent to the computer operator, by DOSC, 
indicating type of load, tapes to be used, tape drive setup, etc. 

e. Tape Generation Request - a work sheet submitted to DOSC, by DOSM, 
listing the items to be loaded to a given vers ion/ subversion. 

4. Tape Designators and Content : DOSC is responsible for maintaining the 
SUOP tape as outlined below: 

a. "M" Tape - The version base tape in maintenance master format. Con- 
tains all the approved items for that version. In addition, in order to 
support testing, the tape will contain the non-standard MOR0 and the Test. 
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NORAD Region (TNR) data base items: Geography, Adaptation and Initial 
Conditions. Local Unique Changes (UCs) will not be loaded to this tape; 
when needed, they will be brought in from PRESTORE. Whenever a version 
is to be released to the field, both the standard MOR0 and the produc- 
tion release values will be reloaded to that version. The item level of 
an "M" tape will always be the same as the corresponding "P" or "T" tape. 

b. "P" Tape - The current official operational master which contains 
all the approved version items, UCs, geography, adaptation, and initial 
conditions. Normally, produced for cycling only when the official opera- 
tional date is reached. The prefix for the supporting adaptation and 
geography tapes will be "PA” and "PG," respectively. 

c. n T M Tape - This tape is a test tape and; 

(1) Prior to the operational date of any given version, it is the 
official SPA test tape. The content is the same as the "M" tape except 
it's in operational format and includes the local unique changes (UCs). 

The tape is authorized to be cycled in support of Active Air Defense (AAD) , 
whenever sufficient confidence has been gained in the version compool. 

Items will only be added after they have been tested and approved by DOSM. 
Version Descriptions (VDs) will be produced and distributed for this type 
of "T" load. The prefix for the supporting adaptation and geography tapes 
is "TA" and "TG," respectively. 

(2) Post operational date of any given version, the "T" tape will 
be used primarily to evaluate future version New Mods (NMs) and Program 
Design Changes (PDCs). Other than these products, the content will be the 
same as the corresponding "P" tape. Version Descriptions (VDs) will not 
be required because the VD written for the corresponding "P" will describe 
the operational changes to both tapes. When correctors issued for a "P" 
tape are not completely compatible with the "T" tape, a dash 1 deck will 
be generated (per 26DOS 01 55-8). 

d. "X" Tape - An operational master containing all the approved items, 
the 25 Air Division's geography, adaptation, and initial conditions. This 
tape is produced, maintained, and cycled in support of testing only. The 
prefix letters for the supporting adaptation and geography tapes will be 
"XA" and "XG," respectively. 

e. "F" Tape - An operational master containing all the approved items, 
the mythical 75 Air Division's environment, geography, adaptation, and 
initial conditions. Until released by Hq ADC, this tape will only be 
cycled, by the SPA, to verify the environment. The prefix letters for the 
supporting adaptation and geography tapes will be "FA" and "FG," respec- 
tively. 

5. SUOP Master Tape Numbering System : The tape designators 
below will be adhered to by DOSC when they generate SUOP tap 
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a. Prior to Operational Date - Letter and three digits (T203) . 

(1) First Letter - Identifies type of tape (see 3a through 3d, 

above) . 

( 2 ) First Digit - Indicates version, using the last digit of 
the version number. 

(3) Last Two Digits - Tape designator - sequentially numbered 
(01 through 99). 

b. Post Operational Date - Letter, two digits, letter (P51B). 

(1) First Letter - Identifies type of tape. 

( 2 ) Two Digits - Indicates version. 

( 3 ) Last Letter - Sub-version tape designator alphabetically 
ordered (A through Z). 

6. Tape S lot Ass ignments : Tapes will be slotted in the cabinets, located 
in front of the tape drive units, as follows: 

Future Version Current Version 


FI 

- "M" Tape 


Cl 

- "M" Tape 

F2 

- "M ,J Tape 

PRESTORE 

C2 

- "M" Tape PRESTORE 


(includes 

UCs ) 


(includes UCs) 

F3 

- COSEAL 


C3 

- COSEAL 

F4 

- RUN 


C4 

- RUN 

F5 

- GIANT 


C5 

- GIANT 

F6 

- UNISIM 


C6 

- UNISIM 

F7 

- SPARS 


C7 

- SPARS 

F8 

- "X" Tape 


C8 

- "X" Tape 

F9 

- "T" Tape 


C9 

- M T" Tape 


F10 - "T" Tape PRESTORE 
Fll - MST N/M BOT 
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7 . Procedures for Submitting Items for Load : 

a. The individual programmers will cycle and test all items prior to 
releasing them, to DOSM, for evaluation and load. The load requests and 
decks will be submitted through the respective division chief. 

b. Division chief will review the requests and authorize the load of 
the item by signing the load requests. 

c. During the phase when both the current and future versions are 
being maintained, a separate load request and card deck will be submitted 
for each version to which a product is to be loaded. For NMs and PDCs, 
the load request will contain the combine tape, DOS tape numbers. 

d. An operationally oriented description, Attachment #1, will be 
attached to the load request of items submitted for load. This descrip- 
tion is not required for NMs and PDCs. 

e. Items submitted for load to a future version will be merged into 
the testing schedule and verified prior to releasing them for load. 

f. DOSM will maintain slides (one each for the future/current version) 
depicting the items submitted for load, testing status and the tentative 
tape load schedule. These slides will be displayed at the DOS weekly staff 
meeting. In addition, DOSM will maintain the load notices on the DOS 
bulletin board whenever loads are scheduled. 

8. Tapeload Procedures : 

a. The availability of items for load will dictate the tape schedule. 
All "PCs" issued will be loaded within 30 days of their release. Normally, 
loads will not be accomplished more often than once every two weeks for any 
given version, although a Category I type "PC" could cause an earlier load. 


b. The necessary card decks, load requests, and tape generation request 
(attachment #2) will be submitted to DOSC, by DOSM, by 1300L, two duty days 
prior to any scheduled load (load freeze date). 

c. DOSC will produce and distribute to DOSM, DOSS, and DOSW a tenta- 
tive tapeload listing (80/80) or the PRESTORE content listing by 0800L, 
the following morning. 

d. The tapeload listing will be reviewed by all concerned and any 
errors, omissions, or necessary revisions will be brought to the attention 
of Chief, DOSM, not later than 1200L. 
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e. After the necessary modifications have been noted, the division 
chiefs will approve the tentative load listing by signing the DOSM copy. 

This copy will be forwarded to DOSC immediately after the Division Chiefs 
have signed it, where it will be used to update the load deck, if required, 
and filed as part of the version load file. 

f. The actual tapeload will be accomplished the following morning 
before normal duty hours. A full systems verification test will be sched- 
uled for the day of the tapeload, normally at about 1100L. If the load 
proves unsuccessful, the other division chiefs will be notified, the full 
systems cancelled, and the load will be rescheduled for the next day or 

as soon thereafter as the problem/condit ion is eliminated. 

g. Immediately after each tapeload DOS C, will conduct a detailed exam- 
ination of the load DLO . This inspection will check for load errors, 
omissions, corrector locations, and sequential order errors. The DLO will 
include the: 

(1) SYC corrector output. 

(2) Tape compare of the new and old tapes. 

(3) Log of the new tape. 

As soon as possible, but before the Full System Verification Test 
(shakedown), DOSM will be notified of the results of the DLO's examination. 
When no errors are found, the individuals who conducted the check will sign 
the DLO listing. It will then be filed as part of the load’s history file. 
If any discrepancies are found, DOSM, coordinating with the other Division 
Chiefs, will determine the magnitude of the error and if necessary cancel 
the shakedown. The load will then be rescheduled per paragraph "e" above. 

h. When the shakedown proves the loads acceptable, DOSM will notify 
DOSC who will slot the tape as follows: 

(1) "M" tapes generated prior to release date will be slotted at 
the time and date indicated in the corresponding "T" tape's Version Descrip- 
tion. The shakedown conducted on the associated "T" tape will suffice for 
both tapes. The procedures outlined in paragraph 7 above apply. 

(2) "M" tapes generated subsequent to release date will normally 
be loaded every 30 days to the level of the most current "P" tape. Shake- 
downs will be required and the tape will not be slotted until a successful 
one has been accomplished. The above tape -load procedures apply. 
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(3) "T" Tapes: 

(a) Produced in support of future version testing will be 
generated by using the corresponding "M" tapes as a base, changing the 
format and adding the UCs . The shakedown performed on the "T” tape will 
satisfy the requirement for both the "M" and "T" tapes. The tapes will 
be slotted when indicated in the Version Description. 

(b) Tape produced in support of NM or PDC checkout will be 
produced by using the corresponding "P" tape as base and adding the NMs, 
PDCs, and the necessary dash ones. Whenever a dash one has been added, 
a shakedown will be required. The tape will be slotted when indicated 
in the corresponding "P" tape VD. 

(4) The initial "P" tape will be produced by using the version 
release tape as a base, subsequent sub-versions will be generated by using 
the preceding "P" as a base. After a successful shakedown, the tape will 
be duplicated in four copies and turned over to computer maintenance and 
will cycle in support of A.A.D. as indicated in the daily Operational 
Order. 


(5) "X M tape will be produced initially for each version and 
updated with all released items, only when a product or corrector has 
been issued which might affect the tapes capability to support testing. 
Shakedowns will not be required and the tape may be slotted after the 
load's DLO has been examined and indicates a good load. 

i. DOSC will maintain a history file of all tapeloads. This file 
will be retained for the life of that version and one additional version. 
Each load file will consist of: 

(1) Copy of the Tape (Generation Request (Attachment #2). 

(2) Copy of the individual item load request. 

(3) The signed copy of the load's 80/80 or the listing of the 
prestore content. 

(4) A copy of the ^on-line Q-7 printout. 

(5) The job sheet (Attachment #3) . 

(6) The signed copy of the load's DLO listing. 

9. Version Description Procedures : A Version Description describing the ; 
content of a load, written in operational language, will be published and 
distributed for every "P" and for every "T" tape produced prior to the 
version's operational date. The format and content will be as outlined 
in the appropriate ADC Manual. Items described in one Version Description 
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will not need to be redescribed when loaded to .another version. Version 
Descriptions will be prepared by DOSM using the Operational Description 
(Attachment #1) which was submitted with the load request. The follow- 
ing procedures apply: 

a. DOSM will review the Operational Description (Attachment #1) for 
content when received. If any clarification is needed, it will be returned 
to the programmer for reaccomplishment. 

b. The content of a load will be frozen at 1200L, two days prior to 
the scheduled load. At that time, the draft of the Version Description 
will be. forwarded to DOS for typing and reproduction. This document will 
be submitted for reproduction as a priority, in order to have it available 
for operational personnel at least three days prior to the version/ sub- 
version cycling. 

c. Distribution of the Version Descriptions will be accomplished as 
specified in the appropriate ADCM. 

10 . Load Policies for Early Released Products : 

a. Products authorized for early release may be loaded to the current 
"M" tape only when they are within ten (10) days of the operational date. 

b. When all of the following are accomplished, products may be loaded 
to the "P" tape : 

(1) Been assigned a "Dated Priority" or authorized for early 
release by Hq ADC. 

(2) The product has been statused as closed. 

(3) All required testing has been successfully completed. 

11. Eouipment Changes : Equipment modification will be identified by DOSM 
and forwarded to DMKD in sufficient time, load freeze date, to allow fox 
the required changes to be implemented prior to the operational date. The 
method of notification will be letter which will contain the specific 
equipment change required, and the time and date by which the modification 
is to be accomplished. When consoles are involved, the letter will contain 

a. Position Name, 
b . Console Number, 
c Module. 
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d. Button affected. 

e. New label/CAT* Switch Change. 

Permament label changes will not be made in support of products undergoing 
SPA testing. 



HERBERT J. S US KIN, Lt Colonel, USAF 
Director of SAGE Programming Agency 
DSC/Operations 
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OPERATIONAL DESCRIPTION 


1. Product Number and Title: 

2. System Affected: 

3. References: 


Description: (Give complete and full details operationally.) 


Actions: (Describe fully all new or changed actions) (switch/lightgun . ) 


Displays: (Describe fully all new display/s resulting from this product.) 


Product Coordinator: 


Phone : 
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FROM: DOSM 


SUBJECT: Tape Generating Request 


TO: DOSC 


1. The following products/mods/correctors are to be loaded on base tape/ 
PRESTORE/BOT. 



2. Testing of this/these item/ items will be accomplished on 
at hours . 


Test Coordinator 


ATTACHMENT 2 
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JOB NUMBER 
PROGRAMMER 

DATE 

EST TIME 


SET UP 

NO. TD 1 TD 2 TD 3 TD 4 TD 5 TD 6 
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DEPARTMENT OF THE AIR FORCE 
Headquarters, 26 Air Division (ADC) 
Luke Air Force Base, Arizona 85301 


2 6 DOS 01 55-14 


23 August 1971 

Operations 

PREPARATION AND MAINTENANCE OF AREA NOTEBOOKS 

Provides a standardized format for the assembly of Area Notebooks per 
the appropriate ADC manuals. This Operating Instruction is applicable 
to all personnel assigned to the SAGE Programming Agency. 

1. Responsibility . Individual programmers are responsible for the 
preparation and continual updating of Area Notebooks for their assigned 
program areas. Division chiefs will periodically review notebooks 
insuring completeness. 

2. Procedures . The individual programmer or programmers for an area 
will prepare and/or secure the items listed below which are applicable 
to his area and available for his use. This information will be func- 
tionally broken down into the following order: 

a. Index. 

b. Area Description (see paragraph 3f). 

c. Program Descriptions (hard copy when available). 

d. Program Design Information and Flow Charts (if available). 

e. Program Specifications. 

f. Current Version Listings. 

g. Current Version TAREFs. 

h. Current Adaptation. 

i. Current Version Analytical Compendium (3255 Documentation - If 
sufficient copies are not available, then applicable page numbers of the 
Analytical Compendium should be referenced.). 

j. Miscellaneous (table formats, items, table included in the Stan- 
dard MOR0, current tape identification for DOSU-assigned systems, etc.). 

k. TPR File: 


This DOS 01 supersedes 260PM 01 55-13, 16 Apr 69, and 260PM 01 55-14, 18 Apr 69. 
OPR: DOSU 
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(1) DCS/SPC (Design Specifications, Program Specifications, 
Analysis Team Study Reports). 

(2) CR/AR (both the Part I and Part II). 

(3) DR /DC. 

(4) P DC/New Mods. 

Note : Feasibility Studies, Test Plans, etc., that pertain to a particular 
product will be filed with that product. Items (1) thru (4) above will be 
kept on file for current and future versions only. 

(5) PR/PG (PIRs will be attached if available). PRs/PCs will be 
maintained together and filed as follows: 

(a) Version. 

(b) Numerically by Air Division, and 

(c) Latest date first. 

PRs/PCs will be kept on file until such time as the program(s) is/are 
remoded and the PC is incorporated into the new mod. 

(6) EPCs - Copies will be maintained until they are incorporated 
or become obsolete. 

(7) UCs - Copies of the current field-wide authorized UCs. 

1. All other information pertaining to future version production. 

3. Maintenance : 

a. The information to be contained in an Area Notebook will be 
assembled into one or more looseleaf binders. Each binder will be labelled 
a "Book" and will be numbered consecutively. If an area requires only one 
binder. Book 1 will contain all information for that area. If an area 
requires more than one binder, then each binder (book) will be numbered, 
beginning with 1 and continuing consecutively. 

b. Each binder will be clearly labelled as to area, book number, and 
the title of the information contained therein: 

EXAMPLE 


TELLING 
BOOK 1 

CURRENT LISTINGS /TAREFS /ADAPTATION 
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£ 


Co An index will be placed in the front of Book 1 specifying the 
location within the book(s) of each of the major topics listed previously 
and any appropriate sub topics. If cross-reference can be made between 
books, then this information will be so stated on the index. 

d. Each book will be carefully prepared with maximum use of reference 
tabs for easy access of information by any programmer. As many binders as 
necessary may be used. 

e. For areas which do not have notebook size listings, the available 
listings will be maintained as a group in a location convenient to the 
responsible programmer. All programmers are responsible for updating 
their assigned area listings upon issuance of TPR-PCs. 

f. An area description will be written and will contain, but not be 
limited to, the following: 

(1) Title. - The commonly used phrase to describe the area. 

(2) References. - List all references used specifically in the 

area. 

(3) Programs Involved. - List all programs in the area. 

(4) Program Overviews. - Give a brief description of what each 
program does. 


HERBERT J. SUSKIN, Lt Colonel, USAF 
Director of SAGE Programming Agency 
DCS/ Operations 
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DEPARTMENT OF THE AIR FORCE 26DOS 01 55-18 

Headquarters, 26 Air Division (ADC) 

Luke Air Force Base, Arizona 85301 3 February 1971 


Operations 
PRODUCT PRODUCTION 

This operational instruction establishes the procedures, practices, and formats 
to be adhered to by the SAGE Programming Agency (SPA) in order to evaluate pro- 
posed programming changes to the SAGE system, design and produce approved pro- 
gramming change suggestions, and develop and publish the necessary documentation 
modifications resulting from the installation of changes to SAGE computer pro- 
gram systems. 


1 . References : 


a. 

b. 


c . 



d. 


e . 


f . 


ADCM 55-32. 
ADCM 55-33. 
ADCM 55-34. 
26DOS 01 55-8. 
26AD HOI 55-18. 
26DOS 01 55-3. 


2. Responsibility : SAGE Programming Agency personnel will comply with the 
procedures contained in this 01 when tasked with design, development and pro- 
duction of the following products: 


a. Design Change Suggestion (DCS). 

b. SAGE Program Change (SPC). 

c. Clarification Request (CR)/Analysis Report (AR) . 

d. Analysis Team Study Report (AT). 

e. Documentation Change Request (DR) /Documentation Correction (DC). 

f. Feasibility Study (FS). 

g. Program Design Change (PDC). 

h. New Program Modification (NM) . 



This document supersedes 26DOS 01 55-18, 17 December 1970. 
OPR: 26DOS 
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3. Terms : The following is an explanation of the terms used in this 01: 

a. ADC System Review Committee (SRC ): A group convening at Hq ADC, which 
evaluates, approves, and disapproves recommended SAGE and BUIC computer program 
changes and the related equipment modifications. 

b. SAGE Programming Agency (SPA ) : The military unit assigned to the 26 Air 
Division responsible for the design, development, testing, acceptance and main- 
tenance of SAGE Versions and associated support and utility systems. 

c. Design Change Suggestion (DCS ) : A request for change or an addition to any 
of the computer programs or equipment controlled by ADCM 55-32, dated 1 Sep 70. 

d. SAGE Program Change (SPC ) : A design change suggestion approved for imple- 
mentation by the SRC. 

e. Technical Programming Report (TPR ) : A document used by military programmers 
to record and disseminate technical information related to the SAGE computer pro- 
gram systems. 


f. Clarification Request (CR ) : A technical programming report requesting 
interpretation or analysis of system documentation. 


g. Analysis Report (AR ) : Documentation produced to close CRs or to imple- 
ment Hq ADC directed program parameter changes. Its primary purpose is to clarify 
design intent of the operational specifications for the SAGE system and when 
required will include changes to the SAGE computer programs’. 


h. Document Change Request (DR) /Document Correction (DC ) 
to identify and correct specific documentation errors. 


TPR documents used 


i. Program Design Change (PDC ) : An improvement to the SAGE computer program 
that may be incorporated provided no change occurs to the operational specifica- 
tions. Documents generated in support of these products will use the letters 
"PD" as the TPR two letter designators. 


j . Feasibility Study Report (FS ) : A document produced in response to an SRC 
request to evaluate a DCS or any other proposed program changes prior to final 
SRC action. 


k. New Program Mod (NM ) : The method of updating SAGE computer programs in 
order to generate spare registers or to retag and recomment the programs. With 
the concurrence of both the SPA committee and the responsible Division Cl?ief, 
NMs may be PDCs. 


1. Product Case File : A file on a product which contains a copy of all 
correspondence and documentation pertaining to or generated during the production 
o f a produc t . 
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m. DCS Review Committee : A group formed to evaluate DCSs received from 
Hq ADC and other field units, prior to SRC action. The evaluation will include 
design, programming, operation and equipment implications. The committee will 
normally convene within the first three working days of each month but can be 
assembled at any time to respond to a Hq ADC Quick Response requirement. 

n. SPA Monthly Status Report : A report produced by the SPA indicating 

the status of all approved products assigned for study or approved for incor- 
poration into the SAGE system. The report will be published monthly as of the 
last Monday of the month. 

o. Product Coordinator ; An individual fixed with the responsibility for 
the design, development and production of a designated product. He is responsi- 
ble for managing and coordinating the efforts of the product team and for the 
administrative effort required to produce the product. 

p. 06 Program Error Correction (06PCs ) : A program correction generated by 
the SPA after the product program specification has been published but before 
the product has been released to the field. The PC will be part of the version 
release package when available. When the correctors are not available on release 
date, the normal program corrector procedures will apply (see 26DOS 01 55-8). 

| q. Preliminary Review Meeting : An assembly of personnel representing all 
functional areas of the SAGE computer program system whose function it is to deter- 
mine the members of the product team, assign tasks, fix tentative milestones and 
identify major problem areas. 

r. Analysis Team Study Report (AT ); Documentation written in support of 
products except when the responsible division chief excuses the requirement due 
to its straight forward design effort or when the change is such a minor nature 
that he feels the AT effort is not warranted. ATs will be generated: 

(1) To keep Hq ADC advised of significant changes in the operational 
concept due to an approved program change. 

(2) When information or guidance is required from Hq ADC. 

(3) To make Hq ADC aware of significant changes in product design and 
development. 

(4) Whenever products are of such complexity as to require a record of 
a rationale used to arrive at the accepted solution. 

s. Design Specifications (PS) : A document in TPR format which describes 
the authorized program change in operational language and contains all the tech- 
nical detail, both mathematical and logical, required to produce the program 
change. In addition, it identifies all equipment and official documentation 
changes required to incorporate the product into the SAGE system. 
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t. Program Specifications (PS ); Documentation, programmer oriented 

in TPR format, which describes in detail all the program changes necessary to 
implement the design specification. The document will also contain changes 
to programmer oriented documentation, i.e., C0MD0C/C0MP00L, etc. 

u. Product Coding ; The computer program coding generated to implement 
the authorized change as outlined in the design and program specifications. 

v. Product Test Plan : A document produced by the product coordinator 
specifying the method which will be used to test products for adherence to the 
design specifications. 

w. Version Release Package ; The magnetic tapes containing the updated 
SAGE programs and the supporting documentation which describes in detail all 
the differences between the current version and the version being released. 

x. Product Team : A group of SPA program area/system specialists whose 
programs are affected by a given product. They are responsible to the 
product coordinator for accomplishing all assigned tasks. 

y. Product Status Board : The master status board located in the DOS 
office which displays the current status of all products being produced by 
the SPA. 


z. Document Change Notice ; A document generated by the SPA providing 
in detail the specific changes required to the Operational Specifications, 
Positional Handbooks, Common Appendix, VDE specifications, Users Manuals 
and Message Formats document. 

4. Procedures : 

a. Procedures for the production of individual products are contained 
in the annexes as indicated; 

(1) Design Change Suggestions (DCS) - Annex 1. 

(2) SAGE Program Change (SPC) - Annex 2. 

(a) Design Specifications (DS) - Annex 2. 

(b) Program Specifications (PS) - Annex 2. 

(3) Clarification Request (CR) /Analysis Report (AR) - Annex 3. 

(4) Documentation Change Request (DR) /Documentation Correction (DC) 

Annex 4 . 


Program Design Change (PDC) - Annex 5. 
New Program Modification (NM) - Annex 6. 


(5) 

( 6 ) 
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(7) Feasibility Study (FS) - Annex 7. 

(8) Analysis Team Study Report (AT) - Annex 8. 

(9) Test Plan - Annex 9. 

b. In the TPR format , the digits "99“ will be used in lieu of the 
version number when the product is an experimental SPC or when the product has 
not been assigned to a version. 

c. The TPR documentation generated in support of SPCs will use the last 
three digits of the SPC number in the TPR number. 

d. SPA published documents will be modified by issuing an “A" change 
(B, C, etc.) or -l's. The A (B, C) changes are written to correct an error 
or oversight in the original document. The -1 changes will be produced when 
the product requires modification because it does not wholly apply due to a 
new mod in one or more of the programs involved. The -1 changes will be 
issued as an errata sheet modifying the basic document, unless the changes 
are of such magnitude as to require a document reissue. Cards produced for 
-1 changes will contain the digit “1" in column 71. Unaffected programs/ 
cards need not be modified to reflect this update (see 26DOS 01 55-3). 

e. The Reference section of documents generated by the SPA will list 
only those documents which are referenced in the body of the product or used 
as an authoritative source document. Documents that are simply being modi- 
fied by the product will appear only in the document change section. 

f. The Document Change section will list the official document number 
and will include the latest modification letter. 

5. Forms ; The following forms are internal working forms used by the SPA 
and when coupled with the other documentation present a complete history of 
the design, development, production, testing, and the documentation changes 
which were necessary to incorporate the product into the SAGE system. 

a. Preliminary Review Meeting Notice (Form 73) ; Used to notify and 
record the members of the preliminary review team. The form identifies the 
document, its classification, title, and location and indicates the time, 
date, and location of the meeting. Produced in two copies by DOSM, one copy 
for the Product Coordinator and one copy to be posted on the DOS Bulletin 
Board. 

b. Minutes of Preliminary Review Meeting (Form 71) : Produced by the 
Product Coordinator and used to record the makeup of the final product team. 
Lists the tentative milestones, identifies obvious problem areas, other 
system interface dependencies, events which might affect the product produc- 
tion, interbranch and interagency liaison requirements, and provides a general 
description of the product design and program implications. 
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c. Document Coordination Form (Form 70) : Initiated by the Product 
Coordinator, to insure that documents produced in support of products are 
concurred with, by personnel concerned, prior to publication. All documents 
produced will be coordinated through all Division Chiefs, with the exception 
of the Test Plans which will be submitted to DOSM through the responsible 
Division Chief. On receipt each reviewer will note suggested changes on an 
attached sheet, check the appropriate box, sign, date and forward to the 
next reviewing official. When the review is complete, the document will be 
returned to the Product Coordinator, modified as required, and returned to 
DOSM prior to publication. 

d. Weekly Status Reports (Form 69) ; Produced by the Product Coordinator 
and submitted to DOSM NLT 1600 each Monday covering the previous week's activ- 
ity of the product team. The report contains changes to the established mile- 
stones, problems encountered, requirement of additional interbranch or inter- 
agency liaison, report of progress on design or program specifications, test- 
ing activity, and, if applicable, reason for inactivity. 

e. SAGE C0MP00L Request (Form 48) ; Submitted by the Product Coordinator 
identifying in specific detail changes to the CQMPOOL and COMDOC documents 
resulting from the design and development of the product. 

f. Analytical Compendium Change Request (Form 51) : Drafted by the Prod- 
uct Coordinator stating in the exact format and content, the necessary changes 
to the Analytical Compendium which are required by the product. 

6. Product Milestones : The following is a list of items which may constitute 
product milestones. These items will be considered at the preliminary review 
meeting and the applicable milestones and dates will be recorded on the pre- 
liminary review meeting Form 71. Once established changes will be submitted 
on the product's Weekly Status Report. 

a. Draft ATSR available for coordination. 

b. ATSR published. 

c. Draft Design Specifications available for coordination. 

d. Design Specifications published. 

e. Test Plan available for coordination. 

f. Tests completed. 

g. Draft Program Specification available for coordination. 

h. Program Specification published. 

i. C0$1P00L/C0MD0C Changes submitted. 
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j. Analytical Compendium Changes submitted. 

k. MOR0 Changes submitted. 


1. Product submitted for testing, 




HERBERT J. SUSKIN, Lt Colonel, USAF 
Director of SAGE Programming Agency 
DCS/Operations 
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ANNEX 1 


DESIGN CHANGE SUGGESTIONS (DCSs) 

Procedures: The procedures for processing DCSs are as follows: 

1. Action by DOSM : 

a. All incoming DCSs received during each calendar month will be filed 
in the unapproved DCS case file. 

b. The Monthly DCS Review Committee meeting will be held within the 
first 3 working days of each month. A notice containing time, date, and 
location of the meeting will be sent to each committee member in sufficient 
time to allow him to review the DCSs and determine its effect on his program 
area. The notice will, in addition, indicate the title, classification, and 
location of the DCSs. 

c. Make the DCSs and pertinent documentation available for review by 
DCS Review Committee members. 

d. Chair the monthly meeting and record the recommendations in the 
minutes. A copy of the minutes will be forwarded to Hq ADC within 3 work- 
ing days following the meeting. 

e. When a quick response is required, the members of the DCS Review 
Committee will be notified of the requirement. A meeting will be conducted 
as soon as all members have had time to review the DCS. The results of the 
meeting will be documented and forwarded to Hq ADC as soon as possible. 

2. Action by DCS Review Committee Members : When notified of the time and 
date of the monthly meeting, he will: 

a. If unable to attend, assign the most experienced available member 
of his division/section to represent him. 

b. Review the DCSs and pertinent documentation to ascertain the impact 
and magnitude of the suggested changes in his area/ system/ program. 

c. Attend the monthly meeting. 

d. Assist in the development of the team's recommendations. 

e. Accomplish assigned tasks which might be required in order to com- 
plete the report. 

3 . Action by DOS : 

a. Forward all DCSs to DOSM. 

b. Type minutes of Monthly Meeting and return to DOSM for proofreading. 
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c. Forward final report to Hq ADC. 

NOTE: 26DOS personnel may initiate DCSs by adhering to the procedures 
contained in paragraph 2-2, Chapter 2, ADCM 55-32. 
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ANNEX 2 

SAGE PROGRAM CHANGES (SPCs) 

1. Procedures ; The procedures for processing SPCs are as follows; 
a. Action by DOSM : 

(1) On receipt of an SPC (approved DCS) open a product case file. 
This file will contain a copy of all documents, correspondence, and forms 
generated in producing the product. The file will be made available to 
anyone having a need to review or study the material. 

(2) Determine the division most affected and contact the Division 
Chief, obtaining the name of the individual who will be assigned as Product 
Coordinator . 

(3) In conjunction with the Product Coordinator determine the time 
date, and location of the Preliminary Review Meeting. 

(4) Notify the respective Division Chiefs of the requirement for 
a Preliminary Review Meeting, indicating time, date, and location. Obtain 
the name(s) of the individual(s) that will represent his system/ program. 

(5) Produce the Preliminary Review Meeting Notice (Form 73) in 
two copies; one for the Product Coordinator and one to be posted on the DOS 
bulletin board. 

(6) Attend the Preliminary Review Meeting, giving any assistance 
required. 

(7) Function as contact point for assistance needed or information 
required from any outside agency or higher headquarters. 

(8) Insure that information received from any outside source per- 
taining to the design, development, and production of the product is for- 
warded to the Product Coordinator, through his Division Chief. 

(9) Monitor the production of the product insuring adherence to 
the scheduled milestones. 

(10) Maintain Product Status Board and note all changes in status 
in the Monthly SPA Report. 

(11) Review and approve all final drafts of documentation, corres- 
pondence, and forms generated in support of the product, insuring complete- 
ness and accuracy prior to submission to DOS for typing on mat. 

(12) Proofread mat and forward to DOSD for publication and distribu 

tion. 
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b. Action by Division Chiefs ; 

(1) When notified by DOSM that a Product Coordinator is required 
from his division he will evaluate the workload and assign his most exper- 
ienced available programmer to the task. 

(2) If notified that representation is required from his division 
for a Preliminary Review Meeting , he will evaluate the workload and assign 
the most experienced available programmer (s) to the team. If determined 

at this meeting that the product does affect his area/system/program, he will 
be assigned as part of the permanent product team. 

(3) Prior to submission* reviews all Weekly Status Reports generated 
by his division in support of the products. 

(4) Coordinates and forwards drafts of all ATSRs, Design Specifica- 
tions, and Program Specifications. 

(5) Approves and forwards Test Plans submitted by the Product Coord- 
inators from his division. 

c. Action by Product Coordinator ; When notified by his Division Chief 
that he has been designated Product Coordinator for a product he will: 

(1) Coordinate with DOSM personnel to determine time, date, and 
location of the Preliminary Review Meeting. 

(2) Review all pertinent documentation and correspondence pertaining 
to the product. 

(3) Chair the Preliminary Review Meeting and document the results 
on the Preliminary Review Meeting Form (Form 71) and submit to DOSM. (See 
paragraph 5b, Basic 01 for content.) 

(4) Using the Weekly Status Report Form (Form 69) submit weekly 
report to DOSM. (See paragraph 5d, Basic 01 for content.) 

(5) Advise DOSM of any problems encountered which might require 
assistance, information, or guidance from higher headquarters or an outside 
agency. 

(6) Conduct Analysis Team activity as required. ATs will be written 
and published as required by paragraph 3r, Basic 01. (Content and format is 
outlined in Annex 8, this 01.) 

(7) Supervise the design, development, and production of the draft 
Design Specifications adhering to the production schedule. (The document 
content and format is outlined in paragraph 2 of this annex.) 
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(8) Produce and submit to DOSM a Test Plan indicating the methods of 
testing. The plan will be in letter form. (See Annex 9 of this 01 for con- 
tent and format.) 

(9) After testing has been completed 3 submit the results in letter 
form to DOSM. The letter will also indicate the areas that could not be 
tested locally. 

(10) Produce a Draft Program Specification, and submit for coordina- 
tion. (The content and format are outlined in paragraph 2 of this annex.) 

(11) When required, produce the COMPOOL/COMDOC Change Request (Form 
48) and the Analytical Compendium Change Request (Form 51) and submit to 
DOSM. 


(12) When MOR0 Changes are required, a card deck will be produce 
and submitted to DOSU. The cards will contain only the control information 
in card columns 18 through 44. 3D0SU will complete the cards and submit for 
load request. The load request and deck will be turned over to DOSM for 
verification prior to tape load. 

(13) Proofread completed mats. Have errors corrected and submit to 

DOSM. 

(14) All documentation, correspondence, and forms in draft form will 
be submitted to DOSM through the Division Chief prior to final action. 

d. Action by Team Member ; When notified that he has been selected as 
a Product Preliminary Review Team Member, he wills 

(1) Review all documentation and correspondence pertaining to the 

product. 

(2) Attend the meeting as specified in the Preliminary Review Meet- 
ing Notice. 

(3) If his area/ system/ program is affected, perform the tasks 
assigned by the Product Coordinator. 

(4) Submit required documentation and forms to the Product Coordi- 
nator . 

e. Action by BOS s 

(1) Forward SPCs (approved DCSs) to DOSM. 

(2) On receipt of approved draft from DOSM, reaccomplish on mat and 
return to the Product Coordinator for proofreading. 

f . Action by DQSD ; 

(1) On receipt of the mats, publish and distribute per the SPA 
Master Distribution List. 

(2) Maintain a record of all Documentation Changes. 
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(1) COSEAL ; Describe the changes to COSEAL at the level of the 
Users Manual. 

(2) GIANT ; Describe the changes to GIANT at the level of the 
Users Manual. 

(3) UNISIM ; Describe the changes to UNISIM at the level of the 
Users Manual. 

d. Initial Data ; 

(1) Environmental Data ; Describe the changes giving the data name, 
description, classification, and the agency providing the value(s). 

(2) Weapons Data ; Describe the changes giving the data name, 
description, classification, and the agency providing the value(s). 

(3) Program Data Control ; Describe the changes giving the data 
name, description, classification, and the agency providing the value(s). 

e. Equipment ; 

(1) 047 Plugboard Wiring ; Describe in detail the changes to the 

wiring. 

(2) Variable Display Equipment ; A detailed description of changes 
to the VDE. 

(3) Other Equipment ; A description of changes to specific equip- 
ment indicating how the equipment is to be modified to be compatible with 
the SPC. 

f. System Interface; 


(1) NORAD COG ; Describe the necessary NORAD COG program changes 
required to eliminate any incompatibilities between the two systems. 

(2) BUIG III ; Indicate any BUIG III program change necessary to 
keep the two systems compatible. 

(3) ARADGOM ; Any changes required of the ARADCOM program to keep 
the two systems compatible. 

(4) Other Systems ; Changes required to any system not covered above. 

g. Documentation Changes ; Identify all documents, by number and title, 
which are to be modified by the product. The documents listed below should 
be considered when this paragraph is being written. In addition, indicate 
that Attachment 1 contains the exact changes to all documentation in specific 
detail, paragraph by paragraph, line for line. 

(1) Operational Specifications (637s). 

(2) SAGE Positional Handbooks. 
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(3) Users Manuals (RUN, SPARS, UNIS IM, and GIANT). 

(4) VDE Specifications. 

(5) 820 and 825 Documents. 

(6) COSEAL Manual. 

(7) FAST Manual. 

(8) Message Formats Documents. 

(9) SPARS Data Base Documents. 

(2) Program Specification (PS): TPR format; content as follows: 


PROGRAM SPECIFICATION 
SPC NUMBER XXXX 


1. Title : 

2. System/ Vers ion/ Programs : Indicate the system or systems affected. Give 
the version number the product is being produced for or the digits , ' B 99. ,, 
Indicate the programs being modified by the product. 

3. References : Cite field-deliverable documents which are used in the main 
body of the SPC as authoritative or source type documents. See paragraph 4e, 

Basic OX. 


4. Description : Short description of the program changes. 

5. SUOP Program Changes : Ordered by program and program tag. Give a detailed 
description of changes to each functional area. 

6. COMPOOL Changes : Describe all additions, deletions, and changes to pro- 
grams, tables, or items. 

7. C0MD0C Changes : Describe in detail C0MD0C changes including scaling, 
bit location, etc. 


a. Environmental Data : Describe changes to the level of Volume 1 of the 
Analytical Compendium. 


b. Weapons Data : Describe changes to the level of Volume 2 of the Analyt- 
ical Compendium. 
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c. Program Control Data : Describe changes to the level of Volume 3 of 
the Analytical Compendium. 

9 . Support Computer Program Systems : 

a. RUN : Same as 5 but for the RUN programs. 

b. SPARS : Same as 5 but for the SPARS programs. 

NOTE : C0MP00L Change to RUN and SPARS will be indicated in this section. 

10. Utility Computer Program Systems : 

a. UNISIM : Same as 5 but for the UNISIM programs. 

b. COSEAL : Same as 5 but for the COSEAL programs. 

c. GIANT : Same as 5 but for the GIANT programs. 

11. Implementing Instructions : 

12. Other Pertinent Information : (When a MOR0 Change is required, indicate 
the item or table to be added or deleted. 

13. Program(s) Corrector Listing: See Attachment. 
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ANNEX 3 

CLARIFICATION REQUEST (CR) /ANALYSIS REPORT (AR) 

1. Procedures : The procedures for processing CR/ARs and Hq ADC directed 
changes are as follows: 

a. Action by DOSM : 

(1) On receipt of a Clarification Request, open a product Case 
File. This file will contain a copy of all documents, correspondence, and 
forms generated in the production of the product. The file will be made 
available to anyone having a need to review or study the material. Reference 
to the CR from this point on will be by AR number. 

(2) On receipt of an ADC-directed Change, obtain an AR number from 
DOS and open an AR Product Case File. 

(3) Determine the division most affected and contact the Division 
Chief, obtaining the name of the individual who will be assigned as Product 
Coordinator. 

(4) In conjunction with the Product Coordinator determine the time, 
date, and location of the Preliminary Review Meeting. 

(5) Notify the respective Division Chiefs of the requirement for a 
Preliminary Review Meeting, indicating time, date, and location. Obtain the 
names of the individuals that will represent his system/ program. 

(6) Produce the Preliminary Review Meeting Notice (Form 73) in two 
copies; one for the Product Coordinator and one to be posted on the DOS 
Bulletin Board. 

(7) Attend the Preliminary Review Meeting giving any assistance 
required. 

(8) Function as contact point for assistance needed or information 
required from any outside agency or higher headquarters. 

(9) Insure that information received from any outside source pertain- 
ing to the design, development, and production of the product is forwarded to 
the Product Coordinator, through his Division Chief. 

(10) Monitor the production of the product insuring adherence to the 
scheduled milestones. 

(11) Maintain Product Status Board and note all changes in status on 
the Monthly SPA Report. 

(12) Review and approve all final drafts of documentation, corres- 
pondence and forms generated in support of the product, insuring completeness 
and accuracy prior to submission to DOS for typing on mat. 
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(13) Proofread mat and forward to DOSCD for publication and distri- 
bution. 



b. Action by Division Chiefs : 

(1) When notified by DOSM that a Product Coordinator is required from 
his division, he will evaluate the workload and assign his most experienced 
available programmer to the task. 


(2) If notified that representation is required from his division 
for a Preliminary Review Meeting, he will evaluate the workload and assign 
the most experienced available prograramer(s) to the team. If determined 
at this meeting that the product does affect his area/ system/ program, he will 
be assigned as part of the permanent product team. 


(3) Prior to submission, reviews all Weekly Status Reports generated 
by his division in support of the products. 


(4) Coordinates and forwards drafts of ATSRs and the Analysis Report 
Parts I and II and all attachments. 

(5) Approves and forwards Test Plans submitted by the Product Coord- 
inators from his division. 


c. Action by Product Coordinator : When notified by his Division Chief 
that he has been designated Product Coordinator for a product he will: 

(1) Coordinate with DOSM personnel to determine time, date, and loca- 
tion of the Preliminary Review Meeting. 

(2) Review all pertinent documentation and correspondence pertaining 
to the product. 


(3) Chair the Preliminary Review Meeting and document the results on 
the Preliminary Review Meeting Form (Form 71) and submit to DOSM. (See para- 
graph 5b, Basic 01 for content.) 

(4) Using the Weekly Status Report Form (Form 69) submit weekly 
report to DOSM. (See paragraph 5d, Basic 01 for content.) 

(5) Advise DOSM of any problems encountered which might require 
assistance, information or guidance from higher headquarters or any outside 
agency . 

(6) Generate an Analysis Team Study Report (AT) in support of the 
product, if required. 

(7) Conduct Analysis Team activity as required. ATs will be written 
and published as required by paragraph 3r>. , Basic 01. Content and format is 
outlined in Annex 8, this 01. 
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(8) Supervise the design, development, and production of the 
Draft Design Specifications (Part I) adhering to the production schedule. 

The document content and format is outlined in paragraph 2 of this Annex. 

(9) Produce and submit to DOSM a Test Plan indicating the methods 
of testing. The plan will be in letter form; see Annex 9 of this 01 for 
content and format. 

(10) After testing has been completed, submit the results in letter 
form to DOSM. The letter will also indicate the areas that could not be 
tested locally. 

(11) Produce a Draft Program Specifications (Part II) and submit 
for coordination, content, and format outlined in paragraph 2 of this Annex. 

(12) When required, produce the COMPOOL/COMDOC Change Request (Form 
48) and the Analytical Compendium Change Request (Form 51). 

(13) When MOR0 Changes are required, a card deck will be produced and 
submitted to DOSU. The cards will contain only the control information in 
card columns 18 through 44. DOSU will complete the cards and submit for load 
request. The load request and deck will be turned over to DOSM for verifica- 
tion prior to tape load. 

(14) Proofread completed mats, correcting errors. Submit to DOSM. 

(15) All documentation, correspondence, and forms in draft form will 
be submitted to DOSM through the Division Chief prior to final action. 

d. Action by Team Member : When notified that he has been selected as a 
Product Preliminary Review Team Member he will: 

(1) Review all documentation and correspondence pertaining to the 

product. 

(2) Attend the meeting as specified in the Preliminary Review Meeting 

Notice. 

(3) If his area/system/program is affected, perform the tasks assigned 
by the Product Coordinator. 

(4) Submit required documentation and forms to the Product Coordina- 
tor. 

e. Action by DOS : 

(1) Forward CRs to DOSM. 

(2) On receipt of approved draft from DOSM, reaccomplish on mat and 
return to the Product Coordinator for proofreading. 
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f . Action by DOSD: 


(1) On receipt of the mats publish and distribute per the SPA 
Master Distribution List. 

(2) Maintain a record of all Changes to documentation. 

(3) Produce and forward to Hq ADC, a Document Change Notice on an 
as required basis. 

2. Official AR Documentation : The following documents, content, and format 
as indicated, comprise the official AR documentation. 

a. Analysis Team Study Report (AT) ; As required, per paragraph 3r, 
Basic 01. Document will be in TPR format; content as outlined in Annex 8, 
this 01. 


b. Analysis Report (AR) ; Published in TPR format; see para e below for 
content. The Part II of the AR will only be produced when there is program 
coding required to close the CR . 


c. Program Error Correction (06 PC) : Published in TPR format; for con- 
tent see Annex E, Chapter 7, ADCM 55-33. These correctors will be delivered 
to the field as part of the Version Release Package, or if not available on 
release date, they will be teletyped as they become available. 

Analysis Report: TPR format and content as follows: 



ANALYSIS REPORT 
PART I 

DESIGN SPECIFICATIONS 


1. Title : 

2. System/Ver sion/Programs : Indicate the system or systems affected. Give 
the version number the product is being produced for or the digits 
Indicate the programs being modified by the product. 

3. References : Cite field-deliverable documents which are used in the main 
body of the AR as authoritative or source- type documents and not those which 
are just to be modified. 

4. Problem : Statement of the problem to be corrected by this AR. This 
should include an exact statement of conflict between current specifications 
and design intent, or ambiguities in the current specifications. 

5. Analysis : The analysis should clarify all aspects of the problem and (Jy 
give a detailed description of the solution. 
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6. Action : 

a. Documentation Changes : Identify all documents, by number and 
title, which are to be modified by the product. The documents listed 
below should be considered when this paragraph is being written. In 
addition, indicate that Attachment 1 contains the exact changes to all 
documentation in specific detail, paragraph by paragraph, line for line. 

(1) Operational Specification (637s). 

(2) SAGE Positional Handbooks. 

(3) Users Manuals (RUN, SPARS, UNISIM, and GIANT). 

(4) VDE Specifications. 

(5) 820 and 825 Documents. 

(6) COSEAL Manual. 

(7) FAST Manual. 

(8) Message Formats Documents. 

(9) SPARS Data Base Documents. 

b. Equipment Changes : 

c. System and Programs Affected : If programs are not affected, indi- 
cate Part II will not be published or list system and programs being modi- 
fied. 
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PART II 

PROGRAM SPECIFICATIONS 

1. SUOP Program Changes ; Ordered by program and program tag. Give a 
detailed description of changes to each functional area, 

2. C0MP00L Changes ; Describe all additions, deletions, and changes to 
programs, tables, or items. 

3. Initial Data Changes ; 

a. Environmental Data ; Describe Changes to the level of Volume 1 of 
the Analytical Compendium. 

b. Weapons Data ; Describe changes to the level of Volume 2 of the 
Analytical Compendium. 

c. Program Control Data ; Describe changes to the level of Volume 3 
of the Analytical Compendium. 

4. C0MD0C Changes : Describe in detail COMDOC Changes including scaling, 
bit location, etc. 

5 . Support Computer Program Systems : 

a. RUN : Same as 1 but for the RUN programs. 

b. SPARS : Same as 1 but for the SPARS programs. 

NOTE : C0MP00L Changes to RUN and SPARS will be indicated in this section. 

6. Utility Computer Program Systems : 

a. UNISIM : Same as 1 but for the UNISIM programs. 

b. COSEAL : Same as 1 but for the COSEAL programs. 

c. GIANT : Same as 1 but for the GIANT programs. 

7 . Implementing Instructions : 

8. Other Pertinent Information: (When a MOR0 Change is required, indicate 
the item or table to be added or deleted.) 

9. Program(s) Corrector Listing : See Attachment 2. 
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ANNEX 4 

DOCUMENTATION CHANGE REQUEST (DR) /DOCUMENTATION CORRECTION (DC) 

1. Procedures ; The procedures for processing Documentation Change Requests 
(DRs) and Documentation Corrections (DCs) are as follows; 

a. Action by DOSM ; 

(1) On receipt of a DR, open a Product Case File. 

(2) Determine the division whose documentation is most affected and 
assign the Division Chief as the Product Coordinator. 

(3) Notify the Division Chief of his selection. 

(4) If unclassified, forward a copy of the Document Change Request 
to the Product Coordinator. If classified, issue to the Product Coordinator 
a Document Coordination Form (Form 70) indicating the location and classifi- 
cation of the DR. 

(5) In conjunction with the Product Coordinator establish a date 
for the completion of the draft DC. 

(6) Monitor the production of the product, assist the Product Coord- 
inator whenever requested and maintain Product Status Board. 

(7) Function as contact point for any information required or assist 
ance needed from higher headquarters or outside agencies. 

(8) Review the draff DC for completeness and accuracy and forward 
to DOS for typing on mat. 

(9) Proofread mat and forward to BOSD.o for publication and distri- 
bution. 

b. Action by Division Chief ; When notified that a DR has been received 
pertaining to documentation in his area, he will; 

(1) Review the DR and in conjunction with DOSM set a date for the 
completion of the draft DC. This date is dependent on the division's work- 
load and the work effort involved in producing the DC. 

(2) Utilizing division personnel, research the documentation and 
generate a draft DC which is required to close the DR. See paragraph 2 for 
content and format. 

(3) Submit the completed draft to DOSM. 

(4) Proofread the typed mat, correcting any errors. 

Forward the mat to DOSM for coordination, publication, and dis- 


(5) 

tribution. 
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c • Action by DOS : 

(1) On receipt, forward the DR to DOSM. 

(2) Type the approved draft DC on mat and return to the Product 
Coordinator for proofreading. 

d. Action by DOSD: ; 

(1) Publish and distribute the DC as required by SPA Distribution 

List. 

(2) Maintain a record of all changes to documentation. 

(3) Produce and forward to Hq ADC a Document Change Notice on an 
as required basis. 

2. Document Correction Content and Format : This type of document correction 
will be published and distributed in order to close DRs. Content and format 
as follows: 


TECHNICAL PROGRAMMING REPORT (TPR) (date) Page of Pages 

TPR No. (Product Coordinator) - Ext 

1. Title : Self-explanatory. 

2. Document Number/ Document Name/Document Date : Self-explanatory. 

3. References : Self-explanatory. 

4. Problem : Self-explanatory. 


5. 


Document Corrective Action : Specific changes to the indicated document. 
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ANNEX 5 

PROGRAM DESIGN CHANGE (PDCs) 

1. General : PDCs may be produced when an improvement to the logic or 
design of a program can be made which does not change the system' s opera- 
tional specification but results in the saving of operational time or reg- 
ister space. PDCs do not necessarily imply a new mod. 

2. Procedures : The procedures for PDC production are: 
a. Action by programmer: 

(1) Submit a request for PDC to his Division Chief. The request 
will be in letter form and will include the following: 

(a) Program and mod to be changed. 

(b) Indicate if any pseudo programs are to be created. 

(c) Indicate what other programs are affected. 

(d) Reason for change. 

(e) Indicate how areas within the program are to be changed. 

(f) Indicate if any and what assistance will be needed. 

(g) The proposed schedule of production: 

1 . Coding to begin. 

2 . Draft Test Plan available. 

3>. Testing to begin. 

4. Cards available for live testing. 

5 „ Draft Program Specification available. 

(2) If the PDC request is approved; design, develop, produce, and 
test the product. 

(3) Submit to DOSM a Status Report every other Monday by 1600L. 
The report will be as of the previous Friday, covering the preceding two 
weeks' activity. The Weekly Status Report Form (69) will be used. 

(4) Advise DOSM of any problems encountered which might require 
assistance. 
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(5) Produce and submit to DOSM a Test Plan indicating the methods 
of testing. The plan will be in letter form; see Annex 9 of this 01 for 
the content and format. 

(6) When test is completed, submit the results in letter form to 
DOSM. The letter will also indicate areas that could not be tested locally. 

(7) Submit for coordination the Draft Program Specification; content 
and format outlined in paragraph 2, this annex. 

(8) When required, produce and submit to DOSM the Analytical Com- 
pendium Change Request (Form 51) and the CQMP00L/C0MD0C Change Request 
(Form 48) . 

(9) Proofread completed mats, correcting any errors and submit to 

DOSM. 

(10) All documentation, correspondence, and forms will be submitted, 
through Division Chiefs, to DOSM prior to final action, 

b. Action by DOSM ; 

(1) Open a Product Case File after the request for PDC has been 
approved. 

(2) Function as contact point for any information required or assist 
ance needed. 

(3) Review and approve the final draft of the Program Specifications 

(4) Verify and forward all documents, correspondence, and forms to 
the appropriate action division. 

(5) Monitor the production of the PDC and note all status changes. 

c. Action by Division Chief s 

(1) Submit the Request for PDC action to the SPA Committee, in order 
to ascertain the impact on other products and/or other systems. 

(2) Support the effort from within his resources and if additional 
assistance is required, notify DOSM. 

(3) Review and approve all documentation generated in support of 

the PDC. 

d. Action by DOSD: : On receipt of mats, reproduce and distribute per 
DOS Master Distribution List. 

3. PDC Documentations PDCs will be produced in TPR format; content as 
follows: 
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PROGRAM DESIGN CHANGE 

1. Program : Program and mod affected. 

2. References : Cite field-deliverable documents which are used as 
authoritative or source- type documents. 

3. Description of Improvement : Short description of the PDC. 

4. Program Areas Description : Brief description of each functional 
area, including subroutines of the PDC. 

5 . Areas of Other Programs Affected : 

6. Description of COMPOOL/COMDOC Changes : 

7 . Description of Analytic Compendium : 

8. Pertinent Information : 

9 . Products Included in the PDC : 

10. Program Correction Listing : Listing of PDC coding will be for an 
overload packet. 




26DOS 01 55-18 


ANNEX 6 

NEW PROGRAM MODIFICATIONS 

1. General : When a requirement sexists and is approved, new program mods 
will be generated to retrieve corrector pool spares and to recomment or 
retag programs. Providing the length of a new mod does not exceed the cur- 
rent C0MP00L program allocation, new mods may be produced and loaded at any 
time independent of C0MP00L generation. Program improvements may be incorpo- 
rated when approved by the responsible Division Chief and coordinated through 
the SPA Committee. 

2. Procedures : The procedures for processing new mods are as follows: 

a. Action by DOSC : 

(1) Monitor the corrector pools in order to determine when it will 
be necessary to generate additional spares. 

(2) Notify DOS and other Division Chiefs that requirement exists to 
generate spares in specific corrector pools. 

(3) Obtain the new program's projected length for C0MP00L alloca- 
tion. 

(4) Obtain the DOS tape number of the new Combined Tape and merge 
into the Systems Combined Tape. 

(5) Submit to DOSD the DLOs of the PAD listing. 

b. Action by Division Chief : When a requirement exists to generate spares 
in corrector pools that have programs in his area of responsibility, he will: 

(1) Have the programmers review their programs to determine if suffi- 
cient spares would be retrieved. 

(2) If the new mod effort appears to be worthwhile, have a New Mod 
Request generated. 

(3) Evaluate any Requests for Program Improvements and approve when 
warranted. 

(4) Submit the request to the SPA Meeting for system impact with 
regard to all other products under production. 

- (5) Review all documents and forms produced in support of the 
new mod. 

(6) Make DOSM aware of any assistance needed which is beyond his 
resources. 
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(7) Monitor the effort for adherence to the Product Plan and ^ 

assuring only approved program changes are made. 

c. Action by Programmer : 

(1) When required, produce a Request for New Mod in letter form 
and submit to his Division Chief. This request will cover the followings 

(a) Base mod to be used. 

(b) Estimated number of registers to be recovered. 

(Lb + I - A - D = Ljj) where: = Length of current base mod. 

Ljj = Length of new mod. I = All Inserts. 

D = Number of Deletes. A = Internal Adaptation 

Registers. 


(c) 

(d) 

(e) 

(f) 
( 8 ) 

if so, specify: 


Reason for remodification. 

Functions to be employed (update, retag, etc.). 

Indicate if a pseudo adaptation program will be created. 
Indicate if other programs are affected. 

Indicate if any program improvements are to be incorporated; 



_1 . Program affected. 

2. Area to be changed. 

3 . Reason for change. 

(h) Tentative version for release. 

(i) Indicate what assistance will be required. 

(j) The proposed schedule of production. 

JL. Date coding will begin. 

2. Date Draft Test Plan available. 

3. Date testing will begin. 

4. Date BOT available for live testing. 

f>. Date Draft Program Specifications available. 
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(2) Implementing the procedures contained in the COSEAL Manual 
Volume 2, Chapter 4, and Volume 3, Chapter 2, develop and produce the 
New Mod. Internal adaptation registers will be removed and incorporated 
as a pseudo program. 

(3) All Interim Remods will have the unique designators numeri- 
cally ordered (i.e., TRC01, TRC02). 

(4) The mod designators for the final Combined Tape will remain 
as presently practiced; that is, just modifying the second letter or digit. 
Reference 26DOS 01 55-3. 

(5) New Mod Status Report will be submitted every other Monday by 
1600L. The report will be as of the previous Friday, covering the preced- 
ing two weeks' activity. The Weekly Status Reports (Form 69) will be used. 

(6) Make DOSM aware of any problems encountered which might require 
assistance and guidance or which might affect the generation of the New Mod. 

(7) Produce and submit to DOSM a Test Plan indicating the methods 
of testing. The plan will be in letter form; see Annex 9 of this 01 for 
content and format. 

(8) After testing has been completed, submit the results in letter 
form to DOSM. The letter will also indicate the areas that could not be 
tested locally. 

(9) Produce and submit for coordination a Draft Program Specifica- 
tion; content and format outlined in paragraph 2 of this annex. 

(10) If required, produce the COMPOOL/COMDOC Change Request (Form 
48) and the Analytical Compendium Change Request (Form 51). The C0MP00L 
Change will indicate the new projected program length. 

d. Action by DOSM : 

(1) Open a Produce Case File after the Request for New Mod has been 
approved. 

(2) Function as point contact for any information required or 
assistance needed. 

(3) Review and approve all final drafts of documentation, corres- 
pondence, and forms generated in support of the New Mod, insuring complete- 
ness and accuracy prior to submission for typing on mat. 

e. Action by DOS ; On receipt of the final draft of the Program Specifi- 
cation, reaccomplish on mat and return to the Product Coordinator for proof- 
reading. 
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f . Action by DOSD : 

(1) Reproduce and distribute the Program Specification, using 
the Master Distribution Listing. 

(2) Using the DLO supplied by DOSC, produce the PAD Listing. 

3. New Mod Documentation ; The New Mod Program Specifications will be 
produced in TPR format; content as follows: 


NEW PROGRAM MODIFICATION 

1. Modification for program . 

2. References : Self-explanatory. 

3. Description of Change : Give a short prose description of how the 
program was modified, including description of any approved program 
improvement. 

4. Program Area Descriptions : Brief description of each functional 
area, including subroutines of the program. 

5 . Other Programs Affected: 


6. COMPOOL/COMDOC Changes : List additions, deletions, and changes to 
any program, table, or item. Describe CGMPOOL Changes in detail; include 
information and bit location. 

7 . Analytical Compendium : 

8. Pertinent Information : 

9. Products Included in New Mod: (SPCs, ARs, PCs) 

10. Retag Reference Dictionary : If retagging was accomplished. 
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ANNEX 7 

FEASIBILITY STUDY (FS) 

1. Procedures ; On receipt of a document or correspondence which requires 
the generation of a feasibility study the following are the procedures that 
will be adhered to; 

a . Action by DOSM ; 

(1) Open a Product Case File. This file will contain a copy of 
all documents and correspondence generated in the production of the product. 
The file will be made available to anyone having a need to review or study 
the material. 

(2) Determine the division most affected and contact the Division 
Chief. Obtain the name of the individual who will be assigned as Product 
Coordinator. 

(3) In conjunction with the Product Coordinator determine the time, 
date, and location of the Feasibility Study Preliminary Review Meeting. 

(4) Notify the respective Division Chiefs of the requirement for 
a Preliminary Review Meeting, indicating time, date, and location. Obtain 
the name(s) of the individual(s) that will represent his system/ program. 

(5) Produce the Preliminary Review Meeting Notice (Form 73) in 
two copies; one for the Product Coordinator and one to be posted on the 
DOS Bulletin Board. 

(6) Attend the Preliminary Review Meeting giving any assistance 
required. 

(7) Function as contact point for assistance needed or information 
required from any outside agency or higher headquarters. 

(8) Monitor the production of the product insuring adherence to 
the scheduled milestones. 

(9) Maintain Product Status Board and note all changes in status 
in the Monthly SPA Report. 

(10) Review and approve the final draft of the Feasibility Study. 

(11) Forward the approved Draft Feasibility Study to DOS for typing. 

(12) Proofread final product prior to release. 

b. Action by Division Chiefs ; 

(1) When notified that a Product Coordinator for a Feasibility Study 
is required, he will assign his most experienced available programmer. 
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(2) When notified that personnel from his division are required 
to form a Feasibility Study Preliminary Review Team, he will assign his 
most experienced available programmer (s) to the team. If, at this meeting, 
it is determined that the product does not affect the programs in his areas, 
he will be released from the team. 

(3) Prior to submission, reviews all Weekly Status Reports gen- 
erated by his division in support of the products. 

(4) Coordinates and forwards all draft documentation generated in 
support of the Feasibility Study. 

c. Action by Product Coordinator s When notified by his Division Chief 
that he has been designated as Product Coordinator for a given Feasibility 
Study, he will: 

(1) Review all documents and correspondence pertaining to the 
Feasibility Study as soon as possible. 

(2) Coordinate with Chief, DOSM, for the following: 

(a) Other system/ program area representation required to form 
the Feasibility Study Preliminary Team. 

(b) Time, date, and location of Preliminary Team Meeting. 

(3) Chair the Preliminary Review Meeting and document the results 
on the Preliminary Review Meeting Form (Form 71) and submit to DOSM. (See 
paragraph 5b, Basic 01, for content.) 

(4) Submit Weekly Status Reports (Form 69) every Monday by 1600L. 

The report will cover the previous week's activity. 

(5) Make DOSM aware of any problems encountered or assistance needed. 

(6) Submit all documents and correspondence in draft form to DOSM, 
through Division Chief. 

(7) Proofread all final products and forward to DOSM. 

d. Action by Team Members : When notified by the Division Chief that he 
has been selected to represent his system/ program at a Feasibility Study Pre- 
liminary Review Meeting, he will: 

(1) Review all documentation and correspondence pertaining to the 
Feasibility Study. 

(2) Attend the meeting as specified in the Preliminary Review Meet- 
ing Notice located and posted on the Bulletin Board. 

(3) If his system/ program is affected, perform tasks assigned by 
the Product Coordinator. 
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(4) Generate documents and correspondence required. Submit to 
Product Coordinator through Division Chief. 

e. Action by DOS : 

(1) Forward the Request for Feasibility Study to DOSM. 

(2) Reaccomplish the approved draft and return to the Product 
Coordinator for proofreading. 

2. Feasibility Study Documentation : The study will be published in TPR 
format content as follows: 


FEASIBILITY STUDY 


1. Title : 

2. References : Cite field-deliverable documents which are used in the 
main body of the FS as authoritative or source- type documents. 

3. Statement of Request/Problem : Give a detailed description of the 
request/problem describing the impact on the different systems /programs. 

4. Discussion and Considerations : Summarize the discussions and consider 
ations covering all important details, exceptions, and agreements and con- 
taining a description of all solutions which were investigated, listing 
the advantages and disadvantages of each. 

5. Conclusions and Recommendations : Provide a concise summary of the 
conclusions and of the alternate and recommended solutions. 
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ANNEX 8 

ANALYSIS TEAM STUDY REPORTS (AT) 

Procedure : Analysis Team Study Reports will be produced in TPR format. 

The two-letter designator “AT" 1 will be used. When produced in support of 
SPCs or in an effort to record the rationale used in complex products, the 
report will be retained in-house. Reports will be published and forwarded 
only when information and guidance is required from Hq ADC or when signifi- 
cant changes in operational concepts will be the result of a product. The 
content is as follows: 


ANALYSIS TEAM STUDY REPORT 
SPC/AR NUMBER 


1 . Title : 

2. References : 

3. Introduction : Statement as to the purpose of the report and list of 
personnel assisting in the generation of the report. 

4. Subject : Briefly describe the problem or events that resulted in 
the publication of the ATSR. 

5. Discussion : Summarize the discussion that occurred at the meeting, 
insuring that all important details, agreements, or exceptions are 
included. Other pertinent data, such as background discussion, may also 
be presented in this section. 

6. Conclusions : Provide a concise summary of the conclusions and action 
recommended by the team. 
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ANNEX 9 
TEST PLANS 

1. General : Test Plans will be produced for all Program Changes governed 
by this 01. The Test Plans will indicate the method and procedures to be 
employed by the Product Coordinator during his testing of the assigned 
product. Test Plans will be submitted to the responsible Division Chief 
for approval and then forwarded to DOSM for coordination and review. The 
complexities of the product involved will govern the detail and content 

of the Test Plans. When the testing has been completed, the Test Plans 
will be retained in the Product Case File. 

2. Format : Test Plans will be produced in TPR format. The two-letter 
designator “TP" will be used to designate Test Plans and the last three 
digits of the product number will be used as the three-digit TPR number. 
The document will contain all items which are underlined below; the other 
items will be included when applicable. 


1. Title : (Title of document being tested) 

2. References : 

3 . Objectives and Requirements : 

4. Detailed Test Procedures : 

5. Computer Time and Configuration: 

6. Other Equipment Required: 

7. Test Tools to be Employed: 

8. Manning Requirements: 

9. Live and SIM Testing Requirements: 

10. Switch Actions and Their Expected Results: 

11. Data Reduction Requirements: 

12. Other Pertinent Information: 
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